Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Russel Winder wrote: On Fri, 2011-01-28 at 12:43 -0300, Leandro Lucarella wrote: Russel Winder, el 28 de enero a las 11:30 me escribiste: [ . . . ] Bazaar does indeed have revision numbers per branch. Note that branch and repository is a different concept in Bazaar, unlike Git and Mercurial where they are fundamentally the same. WRONG about Git. Depends what you thought I was saying . . . AFAIK only in Darcs branch and repository is the same. . . . I think you misunderstood what I meant by my statement. What I was trying to say was that Git and Mercurial have effectively the same ideas of repository and branch (at least from a surface usage perspective -- there are significant differences if you delve deeply). Bazaar has a very different idea of what branch and repository are. So in this respect Git and Mercurial are in the same equivalence class and Bazaar is in a different one. I have no idea where Darcs would sit, I have never used it beyond trying to compile Haskell this time last year. In Mercurial (and AFAIK Git), branches and repositories are completely different concepts. A repository is a folder on your hard drive. A branch is a history line inside a repository so it's not that different from Bazaar. The only difference I see is that Bazaar allows you to clone a single branch (i.e to create a repository that will only contain that single branch) whereas a clone of a Mercurial repository will always contain all the branches that the parent had (don't know about Git). Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Sat, 2011-01-29 at 11:18 +0100, Jérôme M. Berger wrote: [ . . . ] In Mercurial (and AFAIK Git), branches and repositories are completely different concepts. A repository is a folder on your hard drive. A branch is a history line inside a repository so it's not Definitely, this is not at issue. The way Git and Mercurial store information about branches and tags within a repository is very different. This leads to a few observable differences in the way branches and commits behave, but in the main there is similarity not difference. Caveat Git's index of course. that different from Bazaar. The only difference I see is that Bazaar allows you to clone a single branch (i.e to create a repository that will only contain that single branch) whereas a clone of a Mercurial repository will always contain all the branches that the parent had (don't know about Git). This is not quite the right view of Bazaar. In Bazaar, the branch is the only thing that exists: each branch is a standalone entity that may or may not have a working tree. Bazaar also has shared repositories which can act as containers of branches, allowing related branches to share common information thereby saving resources. This is a very, very different concept of repository compared to Mercurial or Git. In Bazaar you do not branch repositories, you branch branches -- which may (or may not) be stored in repositories. As you say with Git and Mercurial you clone repositories. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.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: D Programming Language source (dmd, phobos, etc.) has moved to
Russel Winder Wrote: On Sat, 2011-01-29 at 11:18 +0100, Jérôme M. Berger wrote: [ . . . ] In Mercurial (and AFAIK Git), branches and repositories are completely different concepts. A repository is a folder on your hard drive. A branch is a history line inside a repository so it's not Definitely, this is not at issue. The way Git and Mercurial store information about branches and tags within a repository is very different. This leads to a few observable differences in the way branches and commits behave, but in the main there is similarity not difference. Caveat Git's index of course. that different from Bazaar. The only difference I see is that Bazaar allows you to clone a single branch (i.e to create a repository that will only contain that single branch) whereas a clone of a Mercurial repository will always contain all the branches that the parent had (don't know about Git). This is not quite the right view of Bazaar. In Bazaar, the branch is the only thing that exists: each branch is a standalone entity that may or may not have a working tree. Bazaar also has shared repositories which can act as containers of branches, allowing related branches to share common information thereby saving resources. This is a very, very different concept of repository compared to Mercurial or Git. In Bazaar you do not branch repositories, you branch branches -- which may (or may not) be stored in repositories. As you say with Git and Mercurial you clone repositories. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder The conceptual difference described above seems to me more of an insignificant minor implementation detail than anything else. A git repository can contain one or more branches and you obviously can have more than one repository so this boils down to your personal workflow preferences. In other words you can have multiple repositories for the same project and just use them as branches. Git also provides sub-module support such that one repository contains other repositories. Also, while git clone indeed copies all the upstream branches, it's also simple to track just a specific branch (or any subset) of the upstream branches. It's just a matter of doing a git init with the relevant options instead of relying on the default git clone behavior.
Re: D Programming Language source (dmd, phobos, etc.) has moved to
On Sat, 2011-01-29 at 09:49 -0500, foobar wrote: [ . . . ] The conceptual difference described above seems to me more of an insignificant minor implementation detail than anything else. Not at all. But I am really not going to argue the point any further. D has chosen Git, which is fine. A git repository can contain one or more branches and you obviously can have more than one repository so this boils down to your personal workflow preferences. In other words you can have multiple repositories for the same project and just use them as branches. Git also provides sub-module support such that one repository contains other repositories. Also, while git clone indeed copies all the upstream branches, it's also simple to track just a specific branch (or any subset) of the upstream branches. It's just a matter of doing a git init with the relevant options instead of relying on the default git clone behavior. Yes, but this (except tracking branches) applies to Mercurial as well. And mostly to Bazaar. However note the above. Tracking branches are probably the single most useful thing in Git compared to Mercurial and Bazaar. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.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: DVCS vs. Subversion brittleness (was Re: Moving to D)
Michel Fortin wrote: On 2011-01-28 11:29:49 -0500, Bruno Medeiros brunodomedeiros+spam@com.gmail said: I've also been mulling over whether to try out and switch away from Subversion to a DVCS, but never went ahead cause I've also been undecided about Git vs. Mercurial. So this whole discussion here in the NG has been helpful, even though I rarely use branches, if at all. However, there is an important issue for me that has not been mentioned ever, I wonder if other people also find it relevant. It annoys me a lot in Subversion, and basically it's the aspect where if you delete, rename, or copy a folder under version control in a SVN working copy, without using the SVN commands, there is a high likelihood your working copy will break! It's so annoying, especially since sometimes no amount of svn revert, cleanup, unlock, override and update, etc. will fix it. I just had one recently where I had to delete and re-checkout the whole project because it was that broken. Other situations also seem to cause this, even when using SVN tooling (like partially updating from a commit that delete or moves directories, or something like that) It's just so brittle. I think it may be a consequence of the design aspect of SVN where each subfolder of a working copy is a working copy as well (and each subfolder of repository is a repository as well) Anyways, I hope Mercurial and Git are better at this, I'm definitely going to try them out with regards to this. Git doesn't care how you move your files around. It track files by their content. If you rename a file and most of the content stays the same, git will see it as a rename. If most of the file has changed, it'll see it as a new file (with the old one deleted). There is 'git mv', but it's basically just a shortcut for moving the file, doing 'git rm' on the old path and 'git add' on the new path. I don't know about Mercurial. Mercurial can record renamed or copied files after the fact (simply pass the -A option to hg cp or hg mv). It also has the addremove command which will automatically remove any missing files and add any unknown non-ignored files. Addremove can detect renamed files if they are similar enough to the old file (the similarity level is configurable) but it will not detect copies. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Decision on container design
Michel Fortin napisał:
Is there anything implementation specific in the outer struct that provides
ref semantics to Impl? If not, Container could be generic, parametrized by
Impl type.
You could provide an implementation-specific version of some functions
as an optimization. For instance there is no need to create the Impl
when asking for the length, if the pointer is null, length is zero.
Typically, const function can be implemented in the outward container
with a shortcut checking for null.
I think the reference struct can still be orthogonal to the container.
struct Ref(Impl)
{
private Impl* _impl;
ref Impl impl() @property
{
if (!impl) impl = new Impl;
return *impl;
}
static if (hasLength!Impl)
{
auto length() @property
{
return impl ? impl.length : 0;
}
}
alias impl this;
}
Reusability lightens the burden of the container's author (less fuss for user
implementations) and somewhat standardizes containers as they all must exhibit
a certain API with certain semantics to be able to fit into Ref.
The downside is that the syntax for the most common case (ref semantics) is a
little nosier than for value-like behavior.
--
Tomek
Re: Decision on container design
Tomek Sowiński j...@ask.me wrote:
Michel Fortin napisał:
Is there anything implementation specific in the outer struct that
provides
ref semantics to Impl? If not, Container could be generic,
parametrized by
Impl type.
You could provide an implementation-specific version of some functions
as an optimization. For instance there is no need to create the Impl
when asking for the length, if the pointer is null, length is zero.
Typically, const function can be implemented in the outward container
with a shortcut checking for null.
I think the reference struct can still be orthogonal to the container.
struct Ref(Impl)
{
private Impl* _impl;
ref Impl impl() @property
{
if (!impl) impl = new Impl;
return *impl;
}
static if (hasLength!Impl)
{
auto length() @property
{
return impl ? impl.length : 0;
}
}
alias impl this;
}
Now, other functions may also exploit such a shortcut. How do you plan
to implement that?
Actually, by adopting another idiom, it can be done:
struct Ref(Impl) {
private Impl* _impl;
@property ref Impl impl() {
return *(_impl = (_impl ? _impl : new Impl));
}
alias impl this;
auto opDispatch(string name, T...)(T args) {
mixin(return impl.~name~(_impl,args););
}
}
struct ExampleImpl {
static int length(ExampleImpl* that) {
return that ? *that.actualLength : 0;
}
int actualLength( ) {
return 42;
}
}
Of course, I did not say it was a good idiom. :p
--
Simen
Re: Decision on container design
Michel Fortin napisał: As for the case of Appender... personally in the case above I'd be tempted to use Appender.Impl directly (value semantics) and make fill take a 'ref'. There's no point in having an extra heap allocation, especially if you're calling test() in a loop or if there's a good chance fill() has nothing to append to it. Or take an output range. -- Tomek
Re: Decision on container design
bearophile napisał: This page: http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1 A quotation: 3) Everything is a monitor. In Java and the JVM, every object is a monitor, meaning that you can synchronize on any object. This is incredibly wasteful at the JVM level. Senior JVM guys have indicated large percentage improvements in JVM space and performance if we removed the requirement that every object can be synchronized on. (Instead, you would have specific classes like Java 5 Lock) I have read similar comments in various other places. What about creating a @nomonitor annotation, for D2 classes to not create a monitor for specific classes annotated with it? This may reduce some class overhead. Better just remove it, it's not used often. Besides, there are different locks, one size doesn't fit all. -- Tomek
Re: Is D still alive?
On 27/01/11 6:14 PM, Jonathan M Davis wrote: The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited. Personally, I have _never_ needed to add a min call like that. So, while _you_ may think that it's a common thing to do (and it may be that it is in your code), that doesn't mean that that's generally true. - Jonathan M Davis I agree. I've never needed to add a bounds check like that.
Re: Decision on container design
(2011/01/29 3:31), Andrei Alexandrescu wrote: Today after work I plan to start making one pass through std.container. After having thought of things for a long time, my conclusions are as follows: 1. Containers will be classes. 2. Most of the methods in existing containers will be final. It's up to the container to make a method final or not. 3. Containers and their ranges decide whether they give away references to their objects. Sealing is a great idea but it makes everybody's life too complicated. I'll defer sealing to future improvements in the language and/or the reflection subsystem. 4. Containers will assume that objects are cheap to copy so they won't worry about moving primitives. Any showstoppers, please share. Andrei 1, 2 I think that it is a good policy. There is hardly the superiority that a containers are structs. :-) In the first place I had doubt towards treating structs as classes (OOP). When I use it by such a way, the lack of the default constructor is fatal. 3, 4 If speed is accompanied, the sealing up is useful, but if it is late, there are many unnecessary cases. Because it is thought that a lot of repetition access to the element and life cycles occurs in the case of a container, handling it by the element unit should be high-performance. In addition, for usability, a thing of simple behavior is preferable rather than a complicated thing. However, on the other hand, the design that wrong use is impossible should be considered enough.
assert(object) fails to adhere to the principle of least surprise
If I do
if (object) {
...
}
What happens is fairly obvious, and is equivalent to
if (object !is null) {
}
However, if I do
auto object = new Object();
assert(object);
What I expect to happen is
assert(object !is null);
Just as in the above example. What happens however is the program seg
faults. Why? Because it turns out what DMD turns it (silently) into is
object.checkInvariants(); // Whatever it's called.
This is bad enough, however it gets pants-on-head stupid as *object is
not checked for null*. I think the silent rewrite is bad design, but not
checking for null is so stupid, so obvious to anyone who actually uses
the language, I can't believe it's existed for so long. The fact that
assert(object);
and
import std.exception;
enforce(object);
do different things boggles my mind. One must write
assert(object !is null);
or
assert(!!object);
and every day it's like a giant stabbing pain. A stupid wrong headed
design that makes my experience with D _worse_. Just expose a method for
checking the invariant explicitly, and don't do this silent rewrite
bullshit. Any chance of getting a change of behaviour?
FWIW, GDC doesn't do the rewrite, and SDC (the compiler I'm working on
github.com/bhelyer/sdc) won't either.
Re: assert(object) fails to adhere to the principle of least surprise
A few corrections. On Sat, 29 Jan 2011 12:02:57 +, Bernard Helyer wrote: auto object = new Object(); assert(object); This segfaults if object is null, which is obviously impossible in this example. FWIW, GDC doesn't do the rewrite, On structs, it does the rewrite on class instances (boo!).
Re: assert(object) fails to adhere to the principle of least surprise
Further correction. On Sat, 29 Jan 2011 12:09:41 +, Bernard Helyer wrote: FWIW, GDC doesn't do the rewrite, On structs, it does the rewrite on class instances (boo!). It checks for null then checks the invariant. I think that's a good compromise, given that an object without an invariant passes the assert.
Suggestion: New D front page
Hi! I have been putting some free time into creating a design skeleton for a new http://d-programming-language.orghttp://www.d-programming-language.org/ front page: http://digitalpoetry.se/D%20website/D%20overview%20design.png My main concern is presenting newcomers with an inspiring and relevant first impression of D. I think there is lots to gain by having a more alive front page not based on Ddoc (the rest of the site could still be based on it). I have not attempted adding any visual style to the design myself since its not one of my strengths. It should be made to fit better with the overall theme of d-programming-language.org (although IMO it's currently a bit too dark and foreboding). I must confess to being heavily inspired by http://ooc-lang.org and http://cobra-language.com. As creating this would take a significant time investment, I suggest that some more complex sections of the page could be released after the initial version. I have some background in web development but have been almost exclusively doing professional C++ games development during the last 4 years. I would not mind putting some more work into this but am also hopeful that some others in the D community desire to contribute. Constructive feedback with a minimum of bikeshedding is welcome. (Please avoid discussions about specific textual content for now, its just placeholders). Cheers, Chris
Re: Is D still alive?
Peter Alexander: I agree. I've never needed to add a bounds check like that. While my string processing D code contains many of them :-) I presume I am thinking in Python there. Bye, bearophile
Re: Suggestion: New D front page
Christopher Bergqvist: http://digitalpoetry.se/D%20website/D%20overview%20design.png It's nice and better than the current design. Some suggestions: - Start downlading. Shorten this with Download ... - Edit button on the top right: remove it, and use an edit window, so you are already in edit mode. I'd like https://mozillalabs.com/skywriter/ editing subwindow here. - Get Started and D Zen swap them on the page. See you, bearophile
Re: Suggestion: New D front page
Christopher Bergqvist napisał: Hi! I have been putting some free time into creating a design skeleton for a new http://d-programming-language.orghttp://www.d-programming-language.org/ front page: http://digitalpoetry.se/D%20website/D%20overview%20design.png My main concern is presenting newcomers with an inspiring and relevant first impression of D. I think there is lots to gain by having a more alive front page not based on Ddoc (the rest of the site could still be based on it). I have not attempted adding any visual style to the design myself since its not one of my strengths. It should be made to fit better with the overall theme of d-programming-language.org (although IMO it's currently a bit too dark and foreboding). I must confess to being heavily inspired by http://ooc-lang.org and http://cobra-language.com. As creating this would take a significant time investment, I suggest that some more complex sections of the page could be released after the initial version. I have some background in web development but have been almost exclusively doing professional C++ games development during the last 4 years. I would not mind putting some more work into this but am also hopeful that some others in the D community desire to contribute. Constructive feedback with a minimum of bikeshedding is welcome. (Please avoid discussions about specific textual content for now, its just placeholders). Believe it or not but there was a time when the D page welcomed users with beautiful exemplary code, but as time went by it got pushed off by quotes, current status, news, etc. Looking back, it may have been the reason why I didn't say oh.. um.. NEXT! and stayed with D :) I think we need to go back to the roots. -- Tomek
Re: assert(object) fails to adhere to the principle of least surprise
Bernard Helyer napisał:
If I do
if (object) {
...
}
What happens is fairly obvious, and is equivalent to
if (object !is null) {
}
However, if I do
auto object = new Object();
assert(object);
What I expect to happen is
assert(object !is null);
Just as in the above example. What happens however is the program seg
faults. Why? Because it turns out what DMD turns it (silently) into is
object.checkInvariants(); // Whatever it's called.
This is bad enough, however it gets pants-on-head stupid as *object is
not checked for null*. I think the silent rewrite is bad design, but not
checking for null is so stupid, so obvious to anyone who actually uses
the language, I can't believe it's existed for so long. The fact that
assert(object);
and
import std.exception;
enforce(object);
do different things boggles my mind. One must write
assert(object !is null);
or
assert(!!object);
and every day it's like a giant stabbing pain. A stupid wrong headed
design that makes my experience with D _worse_. Just expose a method for
checking the invariant explicitly, and don't do this silent rewrite
bullshit. Any chance of getting a change of behaviour?
FWIW, GDC doesn't do the rewrite, and SDC (the compiler I'm working on
github.com/bhelyer/sdc) won't either.
http://d.puremagic.com/issues/show_bug.cgi?id=796
Vote up ;)
--
Tomek
structs vs classes
I'm a bit troubled with the class/struct dichotomy. I would prefer them both to use the same keyword. Heap/stack allocation could be specified during instantiation instead. Why? Now you need to choose one over the other. Not even C++ has this limitation. Think about containers for example, should they be classes or structs? Do you want them on the stack or on the heap? I guess it's possible to define the entire container as a mixin now. That would let you have both heap and stack containers share definition, but generally I think that the dichotomy should be abolished.
Re: assert(object) fails to adhere to the principle of least surprise
On 1/29/11, Tomek Sowiński j...@ask.me wrote: http://d.puremagic.com/issues/show_bug.cgi?id=796 Vote up ;) Wow, that is an old-school bug (2007!). :p I wonder which bug report is the oldest one that is still opened.
Re: Suggestion: New D front page
I like it. D's web presence needs work all-round.
Re: Suggestion: New D front page
On 29/01/11 12:56, Christopher Bergqvist wrote: Hi! I have been putting some free time into creating a design skeleton for a new http://d-programming-language.org http://www.d-programming-language.org/ front page: http://digitalpoetry.se/D%20website/D%20overview%20design.png My main concern is presenting newcomers with an inspiring and relevant first impression of D. I think there is lots to gain by having a more alive front page not based on Ddoc (the rest of the site could still be based on it). I have not attempted adding any visual style to the design myself since its not one of my strengths. It should be made to fit better with the overall theme of d-programming-language.org http://d-programming-language.org (although IMO it's currently a bit too dark and foreboding). I must confess to being heavily inspired by http://ooc-lang.org http://ooc-lang.org/ and http://cobra-language.com http://cobra-language.com/. As creating this would take a significant time investment, I suggest that some more complex sections of the page could be released after the initial version. I have some background in web development but have been almost exclusively doing professional C++ games development during the last 4 years. I would not mind putting some more work into this but am also hopeful that some others in the D community desire to contribute. Constructive feedback with a minimum of bikeshedding is welcome. (Please avoid discussions about specific textual content for now, its just placeholders). Cheers, Chris I like it! Definitely a few tweaks needed to it, that page is far more welcoming than anything D has currently though. -- Robert http://octarineparrot.com/
Re: assert(object) fails to adhere to the principle of least surprise
Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 1/29/11, Tomek Sowiński j...@ask.me wrote: http://d.puremagic.com/issues/show_bug.cgi?id=796 Vote up ;) Wow, that is an old-school bug (2007!). :p I wonder which bug report is the oldest one that is still opened. That would be #107: Wrong filename in error message when using a mixin http://d.puremagic.com/issues/show_bug.cgi?id=107 -- Simen
Re: structs vs classes
Jim bitcir...@yahoo.com wrote: I'm only discussing the heap/stack difference. In D you are allowed to safely put your structs on the heap, and unsafely put your classes on the stack. What more do you want? Also, a D struct is POD. It has no vtable, it does not support subtyping except via alias this, and it is simply a different beast from classes. This is a good thing, as you often want such a light-weight abstraction. How would you suppose we retain this if we were to abolish this dichotomy? -- Simen
Re: structs vs classes
Le 29/01/11 14:43, Jim a écrit : I'm a bit troubled with the class/struct dichotomy. I would prefer them both to use the same keyword. Heap/stack allocation could be specified during instantiation instead. Why? Now you need to choose one over the other. Not even C++ has this limitation. Think about containers for example, should they be classes or structs? Do you want them on the stack or on the heap? I guess it's possible to define the entire container as a mixin now. That would let you have both heap and stack containers share definition, but generally I think that the dichotomy should be abolished. The difference between class and struct in D is more than heap or stack allocation. Having a common keyword for them would unwisely mask their fundamental differences (inheritance/polymorphism, reference/value semantics, etc.). Perhaps the suggestion is in fact one that has already been made but for which I can't remember the conclusion: how about abandoning 'new' in favor of more specific keywords/library templates that control whether the instantiation occur on the heap or on the stack?
Re: structs vs classes
Jim napisał: I'm only discussing the heap/stack difference. Classes with value semantics would be prone to the slicing problem. -- Tomek
Re: Suggestion: New D front page
On 01/29/2011 01:56 PM, Christopher Bergqvist wrote: Hi! I have been putting some free time into creating a design skeleton for a new http://d-programming-language.orghttp://www.d-programming-language.org/ front page: http://digitalpoetry.se/D%20website/D%20overview%20design.png My main concern is presenting newcomers with an inspiring and relevant first impression of D. I think there is lots to gain by having a more alive front page not based on Ddoc (the rest of the site could still be based on it). I have not attempted adding any visual style to the design myself since its not one of my strengths. It should be made to fit better with the overall theme of d-programming-language.org (although IMO it's currently a bit too dark and foreboding). I must confess to being heavily inspired by http://ooc-lang.org and http://cobra-language.com. As creating this would take a significant time investment, I suggest that some more complex sections of the page could be released after the initial version. I have some background in web development but have been almost exclusively doing professional C++ games development during the last 4 years. I would not mind putting some more work into this but am also hopeful that some others in the D community desire to contribute. Constructive feedback with a minimum of bikeshedding is welcome. (Please avoid discussions about specific textual content for now, its just placeholders). A great improvement! Still needs some talk about the welcome page structure, content, organisation. Maybe a short paragraph on top about the language itself: what it wants (not) to be. All more specific info should be placed on dedicated pages pointed from there --including announcements commits: that is not what newcomers /first/ wish to find; for others, it's only one click away. Pointers to presentation, introduction, tutorials, should be in good, obvious, place; inside Get Started probably. Pointers to language library refs should also be present for advanced programmers or language designers wishing a more technical description. +++ for code sample, Zen of D (complementary to short paragraph evoked above), Featured Projects. I'd see: D prog lang -- motto ... short presentation paragraph ... --- --- --- | code sample| Zen of D | --- --- --- --- --- |Get Started | --- --- --- --- --- | pointers | Feat. Projects | --- --- --- logos legal thing May not be so squarely laid out ;-) Then only, discuss about actual contents and style. Denis -- _ vita es estrany spir.wikidot.com
Re: Suggestion: New D front page
On 1/29/11 5:56 AM, Christopher Bergqvist wrote: Hi! I have been putting some free time into creating a design skeleton for a new http://d-programming-language.org http://www.d-programming-language.org/ front page: http://digitalpoetry.se/D%20website/D%20overview%20design.png My main concern is presenting newcomers with an inspiring and relevant first impression of D. I think there is lots to gain by having a more alive front page not based on Ddoc (the rest of the site could still be based on it). I have not attempted adding any visual style to the design myself since its not one of my strengths. It should be made to fit better with the overall theme of d-programming-language.org http://d-programming-language.org (although IMO it's currently a bit too dark and foreboding). I must confess to being heavily inspired by http://ooc-lang.org http://ooc-lang.org/ and http://cobra-language.com http://cobra-language.com/. As creating this would take a significant time investment, I suggest that some more complex sections of the page could be released after the initial version. I have some background in web development but have been almost exclusively doing professional C++ games development during the last 4 years. I would not mind putting some more work into this but am also hopeful that some others in the D community desire to contribute. Constructive feedback with a minimum of bikeshedding is welcome. (Please avoid discussions about specific textual content for now, its just placeholders). Cheers, Chris I like it. As the guy responsible for the rather dark and foreboding current look and feel of the current d-programming-language.org I'd be happy to work to make this fit the current look and feel as well as alter the look and feel to match this direction. It is very much in line with ideas I've had for improving the welcome page. I'm currently a web dev guy and wouldn't mind contributing time to help develop the necessary code. Andrei or others, if you like this direction could you let us know what web technologies/languages your server supports?
Re: structs vs classes
biozic Wrote: Le 29/01/11 14:43, Jim a écrit : I'm a bit troubled with the class/struct dichotomy. I would prefer them both to use the same keyword. Heap/stack allocation could be specified during instantiation instead. Why? Now you need to choose one over the other. Not even C++ has this limitation. Think about containers for example, should they be classes or structs? Do you want them on the stack or on the heap? I guess it's possible to define the entire container as a mixin now. That would let you have both heap and stack containers share definition, but generally I think that the dichotomy should be abolished. The difference between class and struct in D is more than heap or stack allocation. Having a common keyword for them would unwisely mask their fundamental differences (inheritance/polymorphism, reference/value semantics, etc.). Perhaps the suggestion is in fact one that has already been made but for which I can't remember the conclusion: how about abandoning 'new' in favor of more specific keywords/library templates that control whether the instantiation occur on the heap or on the stack? Yes, abandoning new if it would help. Objects on the heap could be managed by different garbage collectors (or with different settings, mark-sweep, precise/conservative, reference-counting, etc.). I don't want to have to change the definition of the type. The instantiation is a separate concern to the implementation. It should be up to the user of a type to decide whether to allocate it on the stack or the heap and so on. The compiler should be intelligent enough to see whether the class is derived or not and do its optmisations accordingly.
Re: Suggestion: New D front page
On 01/29/2011 04:04 PM, David Gileadi wrote: I like it. As the guy responsible for the rather dark and foreboding current look and feel of the current d-programming-language.org I'd be happy to work to make this fit the current look and feel as well as alter the look and feel to match this direction. It is very much in line with ideas I've had for improving the welcome page. I wish you would avoid white backgrounds (hurt eyes). Since probably many are not fan of light-on-dark, pastel bg colors do the job nicely. (Then, it's a question of taste... ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: structs vs classes
Simen kjaeraas Wrote: Jim bitcir...@yahoo.com wrote: I'm only discussing the heap/stack difference. In D you are allowed to safely put your structs on the heap, and unsafely put your classes on the stack. What more do you want? Also, a D struct is POD. It has no vtable, it does not support subtyping except via alias this, and it is simply a different beast from classes. This is a good thing, as you often want such a light-weight abstraction. How would you suppose we retain this if we were to abolish this dichotomy? -- Simen Oh? All class-based objects are dynamically allocatedunlike in C++, there is no way to allocate a class object on the stack. - The D Programming Language, chapter 6. The lightweight nature of structs is very appealing though. I like that very much of course. Couldn't that be optimised by the compiler alone knowing that a class wasn't derived?
Re: structs vs classes
On 01/29/2011 09:13 AM, Jim wrote:
so Wrote:
I'm a bit troubled with the class/struct dichotomy. I would prefer them
both to use the same keyword. Heap/stack allocation could be specified
during instantiation instead. Why? Now you need to choose one over the
other. Not even C++ has this limitation.
This keeps coming and i have no idea how people think C++ treatment is any
way good.
You are free to call the D design of struct/class the worst possible, but
at least don't base your reasoning to C++ please.
C++: both class and struct are exactly same, except one trivial:
struct A : B {
};
means:
class A : public B {
public:
};
In D they are quite different and they have different keywords.
http://www.digitalmars.com/d/2.0/class.html
http://www.digitalmars.com/d/2.0/struct.html
I'm only discussing the heap/stack difference.
That is of course a difference, but no argument. The reason is that you
can decide whether you want to allocate a class on the stack:
http://www.digitalmars.com/d/2.0/memory.html#stackclass
Matthias
Re: Suggestion: New D front page
On 1/29/11 9:04 AM, David Gileadi wrote: I'm currently a web dev guy and wouldn't mind contributing time to help develop the necessary code. Andrei or others, if you like this direction could you let us know what web technologies/languages your server supports? I like David's design, but it isn't much more than a tasteful rework of the previous one. The design proposed by Chris blew my mind. More than the nice example I like the dynamism - various components are pulled off dynamically, which makes revisiting worthwhile. I'm in charge of d-programming-language.org, which will (when ready) become the default landing page of D. However, it's served off Walter's server. When I want some functionality (such as rsync recently), I ask Walter, who relays the request to the server owner (Jan Knepper), who deploys it. So I'm not sure what technologies are available, but Walter and Jan should be able to respond. This is very exciting! Andrei
Re: Suggestion: New D front page
On Sat, 2011-01-29 at 08:04 -0700, David Gileadi wrote: [ . . . ] I like it. As the guy responsible for the rather dark and foreboding current look and feel of the current d-programming-language.org I'd be I think the current page style looks fine, actually I like it and do not consider it dark and foreboding (*). This is not though a vote for not changing if there is something that is going to be more appealing to a wider range of programmers. (*) Or maybe I am just depressed and it fits with the sense of doom and despondency ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.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: Suggestion: New D front page
On Sat, 2011-01-29 at 16:14 +0100, spir wrote: [ . . . ] I wish you would avoid white backgrounds (hurt eyes). Since probably many are not fan of light-on-dark, pastel bg colors do the job nicely. (Then, it's a question of taste... ;-) I absolutely abhor high contrast websites, i.e. ones with white backgrounds, (take note Google) and navigate away from them as soon as possible, or even immediately. I much prefer muted medium contrast websites. It is not just taste, though that is much of it, it is also an issue of some people having vision issues. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.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: structs vs classes
Jim bitcir...@yahoo.com wrote: All class-based objects are dynamically allocated—unlike in C++, there is no way to allocate a class object on the stack. - The D Programming Language, chapter 6. That would probably be better written as there is no built-in way to allocate a class object on the stack. D is a pragmatic system programming language. If you want to treat this blob of memory as a Foo, and you're willing to jump through some hoops, it can be done. But the language does not encourage this. Like I said, putting a class on the stack is an unsafe thing to do (see http://en.wikipedia.org/wiki/Object_slicing), and it was deemed that the language should not directly support such an idiom. It is still doable in a library. The lightweight nature of structs is very appealing though. I like that very much of course. Couldn't that be optimised by the compiler alone knowing that a class wasn't derived? Perhaps, in some cases. Final classes might. If a class is not marked final, someone might derive from it, include this from a DLL or otherwise, and boom goes the program. -- Simen
Q: Is there a (different) work-around for AA.keys problems?
Howdy,
I'm jammed up against a variation of the issue#3745/3770 AA linkage problem.
In my case, I'm using an int[ string ] AA, and I'm getting the dreaded
Error 42: Symbol Undefined
_D6object28__T16AssociativeArrayTAyaTiZ16AssociativeArray4keysMFNdZAAya
My code looks something like:
class gc_enum : subscriber
{
int[ string ] gc_label_index;
// ...
void assign_gc_enum_vals( )
{
sorted_labels = gc_label_index.keys;
sorted_labels.sort;
// ...
}
Looking in the rtl sources, I don't see that function in aaA.d. Maybe
it's in a different file, or maybe the compiler is supposed to magically
rewrite those accesses into something totally different.
I've been trying to get all my code into a single file, as that seems to
be a work-around, but I'm wondering if there are other ways to work
around this problem?
Thanks,
=Austin
Re: Q: Is there a (different) work-around for AA.keys problems?
Shooting in the dark here (I can't reproduce the error for
whatever reason), but for similar problems, I've found this fixes
it:
Add a function somewhere in your file that says:
void hackAroundBug() {
writeln(typeid(int[string]));
}
You never actually need to call it. Just putting it there gives
the compiler that extra nudge to put the symbol back into the
object file.
The error I saw was related to .rehash being missing, but it
fixed it for me and might work here too.
My older method was to add
-I/home/me/d/dmd2/src/druntime/src /home/me/d/dmd2/src/druntime/src/object_.d -d
On to the DMD command line (object_.d has the code needed for
various AA things). Of course remember to fix the paths there
to your dmd source.
But with the referencing typeinfo workaround, I haven't needed
to do this at all anymore.
Re: structs vs classes
Simen kjaeraas Wrote: Jim bitcir...@yahoo.com wrote: All class-based objects are dynamically allocatedâunlike in C++, there is no way to allocate a class object on the stack. - The D Programming Language, chapter 6. That would probably be better written as there is no built-in way to allocate a class object on the stack. D is a pragmatic system programming language. If you want to treat this blob of memory as a Foo, and you're willing to jump through some hoops, it can be done. But the language does not encourage this. Like I said, putting a class on the stack is an unsafe thing to do (see http://en.wikipedia.org/wiki/Object_slicing), and it was deemed that the language should not directly support such an idiom. It is still doable in a library. The lightweight nature of structs is very appealing though. I like that very much of course. Couldn't that be optimised by the compiler alone knowing that a class wasn't derived? Perhaps, in some cases. Final classes might. If a class is not marked final, someone might derive from it, include this from a DLL or otherwise, and boom goes the program. -- Simen Okay, thanks! I learned some from this thread.
Re: Q: Is there a (different) work-around for AA.keys problems?
The hackAroundBug()/typeid approach didn't work for me - I still got the
error 42. Presently, I'm using a local method, but this is annoying for
obvious reasons:
string[] aa_keys( int[ string ] aa )
{
return aa.keys;
}
Even more annoying is that this works, while a simple reference to the
member.keys in the calling method doesn't. I wonder if this is caused by
the AA being inside an object?
=Austin
On 1/29/2011 11:17 AM, Adam D. Ruppe wrote:
Shooting in the dark here (I can't reproduce the error for
whatever reason), but for similar problems, I've found this fixes
it:
Add a function somewhere in your file that says:
void hackAroundBug() {
writeln(typeid(int[string]));
}
You never actually need to call it. Just putting it there gives
the compiler that extra nudge to put the symbol back into the
object file.
The error I saw was related to .rehash being missing, but it
fixed it for me and might work here too.
My older method was to add
-I/home/me/d/dmd2/src/druntime/src /home/me/d/dmd2/src/druntime/src/object_.d -d
On to the DMD command line (object_.d has the code needed for
various AA things). Of course remember to fix the paths there
to your dmd source.
But with the referencing typeinfo workaround, I haven't needed
to do this at all anymore.
Re: Suggestion: New D front page
Andrei or others, if you like this direction could you let us know what web technologies/languages your server supports? If you have native binary cgi support, it could run D! I started writing this site in D (imo this newsgroup has too much talk and too little action as a general rule). http://arsdnet.net/d-web-site/ You can view it's source here: http://arsdnet.net/d-web-site/site.d And the HTML (with inline CSS) here: http://arsdnet.net/d-web-site/index.html All the helper modules it uses are available here: http://arsdnet.net/d-web-site/arsd/
Re: Decision on container design
On 28.01.2011 19:31, Andrei Alexandrescu wrote: 1. Containers will be classes. 2. Most of the methods in existing containers will be final. It's up to the container to make a method final or not. 3. Containers and their ranges decide whether they give away references to their objects. Sealing is a great idea but it makes everybody's life too complicated. I'll defer sealing to future improvements in the language and/or the reflection subsystem. 4. Containers will assume that objects are cheap to copy so they won't worry about moving primitives. Not perfectly what I would like, but a reasonable choice, and most important to actually have a mature container-lib. But there are other choices remaining: what containers will be there and what will they be called? My suggestion is * Set, MulitSet, Map, MultiMap (hash-table based) * OrderedSet, OrderedMultiSet, OrderedMap, OrderedMultiMap (tree-based) * Sequence (like stl-Deque. the name is just more intuitive. Funny enough, the stl-deque implemenation has nothing to do with a doubly linked list) * Array (like stl-vector. I think vector is a kinda strange name, but that may be only my impression) * List (linked list) * Stack/Queue/PriorityQueue should be done on top of an other class, with a impl-template-param, like the stl-ones Things to note: * container should be named with respect to their use, not the implementation. HashSet is a bad name, because the user shouldnt care about the implemenation. * unordered sets are used more often than ordered. So it should be Set/OrderedSet, and not UnorderedSet/Set (also, the first one is two characters less typing *g*) * opEqual should work between different types of Sets (or Maps, or sequences). Nothing wrong with comparing an ordered to an unordered one, or a list to an array. just my 2 cents, Krox
Re: Decision on container design
Simon Buerger: * container should be named with respect to their use, not the implementation. HashSet is a bad name, because the user shouldnt care about the implemenation. This is good for a language like Python, or even Java, but for a system language I want to know the algorithms I'm using under the hood. So I am not sure. Bye, bearophile
Re: structs vs classes
On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński j...@ask.me wrote: Jim napisał: I'm only discussing the heap/stack difference. Classes with value semantics would be prone to the slicing problem. That is because of the type system not classes or value semantic cause of that. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: structs vs classes
Matthias Walter napisał: That is of course a difference, but no argument. The reason is that you can decide whether you want to allocate a class on the stack: http://www.digitalmars.com/d/2.0/memory.html#stackclass AFAIR scope classes are to be banished from the language. There's emplace instead. http://digitalmars.com/d/2.0/phobos/std_conv.html#emplace -- Tomek
Re: Decision on container design
On Jan 30, 11 01:09, Simon Buerger wrote: On 28.01.2011 19:31, Andrei Alexandrescu wrote: 1. Containers will be classes. 2. Most of the methods in existing containers will be final. It's up to the container to make a method final or not. 3. Containers and their ranges decide whether they give away references to their objects. Sealing is a great idea but it makes everybody's life too complicated. I'll defer sealing to future improvements in the language and/or the reflection subsystem. 4. Containers will assume that objects are cheap to copy so they won't worry about moving primitives. Not perfectly what I would like, but a reasonable choice, and most important to actually have a mature container-lib. But there are other choices remaining: what containers will be there and what will they be called? My suggestion is * Set, MulitSet, Map, MultiMap (hash-table based) * OrderedSet, OrderedMultiSet, OrderedMap, OrderedMultiMap (tree-based) * Sequence (like stl-Deque. the name is just more intuitive. Funny enough, the stl-deque implemenation has nothing to do with a doubly linked list) A 'deque' just mean a double-ended queue, not necessarily doubly linked list. I don't like the name Sequence since it doesn't specify the container can be modified from both ends. 'Deque' is just fine. * Array (like stl-vector. I think vector is a kinda strange name, but that may be only my impression) * List (linked list) * Stack/Queue/PriorityQueue should be done on top of an other class, with a impl-template-param, like the stl-ones Things to note: * container should be named with respect to their use, not the implementation. HashSet is a bad name, because the user shouldnt care about the implemenation. Except that there is already a std.container.RedBlackTree named in this fashion :). * unordered sets are used more often than ordered. So it should be Set/OrderedSet, and not UnorderedSet/Set (also, the first one is two characters less typing *g*) * opEqual should work between different types of Sets (or Maps, or sequences). Nothing wrong with comparing an ordered to an unordered one, or a list to an array. This breaks transitivity of '==' unnecessarily. I don't see the benefit of comparing two different kinds of containers. If you really need to compare them, use std.algorithm.equal. just my 2 cents, Krox
Re: Suggestion: New D front page
Russel Winder napisał: I think the current page style looks fine, actually I like it and do not consider it dark and foreboding (*). This is not though a vote for not changing if there is something that is going to be more appealing to a wider range of programmers. (*) Or maybe I am just depressed and it fits with the sense of doom and despondency ;-) You're not depressed, just subconsciously keen on prolonging your eye-sight ;-) Let's blend Chris' dynamic layout with David's toned color scheme, shall we? -- Tomek
Re: Decision on container design
bearophile Wrote: Simon Buerger: * container should be named with respect to their use, not the implementation. HashSet is a bad name, because the user shouldnt care about the implemenation. This is good for a language like Python, or even Java, but for a system language I want to know the algorithms I'm using under the hood. So I am not sure. There could be an interface named Set and various implementations of it, e.g. HashSet. I think this would be a good principle in general for all abstract collection types.
Re: Decision on container design
In general I actually like this idea, but can we still have sealed ref-counted arrays and associative arrays somewhere in Phobos (not necessarily any more esoteric containers than these and not necessarily in std.container, maybe in a new module called std.refcounted or something)? For huge arrays/AAs I think ref counting is an important optimization, especially with the GC in its current state but to a lesser extent even when we get a better GC. GC tends to be slow compared to manual memory management in cases where most allocated blocks are large. Also, I like reference counting for huge arrays/AAs enough that I submitted a ref counted hash table implementation to the Phobos list for review, which noone seemed to notice. Please comment. On 1/28/2011 1:31 PM, Andrei Alexandrescu wrote: Today after work I plan to start making one pass through std.container. After having thought of things for a long time, my conclusions are as follows: 1. Containers will be classes. 2. Most of the methods in existing containers will be final. It's up to the container to make a method final or not. 3. Containers and their ranges decide whether they give away references to their objects. Sealing is a great idea but it makes everybody's life too complicated. I'll defer sealing to future improvements in the language and/or the reflection subsystem. 4. Containers will assume that objects are cheap to copy so they won't worry about moving primitives. Any showstoppers, please share. Andrei
Re: Decision on container design
On 01/29/2011 12:54 PM, dsimcha wrote: Also, I like reference counting for huge arrays/AAs enough that I submitted a ref counted hash table implementation to the Phobos list for review, which noone seemed to notice. Please comment. Where is it? Andrei
Re: Decision on container design
http://www.dsource.org/projects/aa/browser/trunk/randAA/randaasealed.d On 1/29/2011 2:18 PM, Andrei Alexandrescu wrote: On 01/29/2011 12:54 PM, dsimcha wrote: Also, I like reference counting for huge arrays/AAs enough that I submitted a ref counted hash table implementation to the Phobos list for review, which noone seemed to notice. Please comment. Where is it? Andrei
Re: What Makes A Programming Language Good
Le 18/01/2011 11:45, bearophile a écrit : Vladimir Panteleev: So, you want D to force people to do more work, out of no practical reason? When you develop a large system, the nice hand holding that works with small systems often stops working (because the whole language ecosystem is often not much designed for hierarchical decomposition of problems). In this situation you are often on your own, and often the automatic features work against you because their work and actions are often opaque. So those programmer develop a mistrust toward a compiler+tools that hold too much your hand. A related problem is visible in old automatic pilot systems. They are very useful, but when their operative limits are reached (because some emergency has pushed the plane state outside them), they suddenly stop working, and leave the human pilots in bad waters because the humans don't have a lot of time to awake from their sleepy state and understand the situation well enough to face the problems. So those old automatic pilot systems were actively dangerous (new automatic pilot systems have found ways to reduce such problems). To solve the situation, the future automatic D tools need to work in a very transparent way, giving all the information in a easy to use and understand way, showing all they do in a very clear way. So when they fail or when they stop being enough, the programmer doesn't need to work three times harder to solve the problems manually. Bye, bearophile My 2 cents: There is no need for transparency in the compilation and linking processes if things are well defined. Armies of developers in Java shops that include banks trust their IDE to do almost everything, be it eclipse, Netbeans or IntelliJ, sometimes the 3 at the same time in the same team. This is the case in my team, where some developers use IntelliJ while others use eclipse, out of the same source code repository. Both IDEs can compile and debug the software and the final build is made by a big ant file which can check out, generate code, build with javac and run tests. So there are 3 build systems in parallel. One task of the ant file is run once by each developer to generate the code and then the build is entirely handled by the build system, is the compiler of the IDE. There is no need to specify any dependency in the ant file. Of course, the IDE's compiler needs to be told where to find the library dependencies because we don't use Maven yet, but apart from taht, there is no need to specify anything else. This is in contrast with the horrible makefiles that still cripple most C++ projects, and still prevent C++ shops to benefit from efficient IDEs. Having worked both on large C++ systems and Java systems, my only conclusion is: make is a huge waste of time.
review for unittests
I made one more pass through the unittests library and it looks fine, but I still find it wanting. Overall: * From too few examples now it has too many! The fine line is somewhere in between (I'd say on the short side). I complained about the initial documentation because the example were meaningless (e.g. they used names that weren't defined. The current iteration of the library gives so many examples it's patronizing. Yes, if you give the list of operators supported, you don't need to give an example of each! We're not oligophrenes over here. * To add insult to injury, examples have a double-spacing that is a bit much. * The code has a lot of lines beyond 80 characters. 80 characters should be plenty to write good code, and makes for readable code that doesn't need to occupy one's entire screen. I wish I could somehow convince everybody to not complain, not debate, and not show me the old style guide. Let's just write 80-columns code. That includes documentation. Please. Let's. * Even examples are sometimes too wide - some don't fit in my browser unless I enlarge it considerably. * I don't mean to belittle the effort, but the documentation needs one more pass for typos etc. I wouldn't mention this if I hadn't noticed Jonathan is otherwise a perfect speller and a good writer. So, it's Generally speaking not Generally-speaking, given set not give set... and that's just the first line. Eliminate all flowery: there's no need for generally speaking and in essence particularly etc. etc. etc. * For inline code use $(D ) not anything else * I appreciate the date-based examples but I'd rather stick with one focus at a time. * There's got to be too much of a good thing. The massive unittests, the lavish waste of vertical space (import with commas, anyone?) and the documentation make adding four simple concepts a 1887 lines deal. I guess that's borderline okay but I am increasingly hawkish about massive additions of small functionality to Phobos. * The documentation for the mock-up assertPred could be moved up to the module documentation, which has the advantage that it avoids any self-explaining: There is further documentation for each version below (this particular version of the function doesn't actually exist - it's here so that there's a good spot to put documentation for the function as a whole). Why would anyone need to absorb that kind of information in order to use four simple concepts? My vote is in favor to adopting this library, contingent upon (a) making a spelling and correctness pass and (b) giving the documentation a thorough haircut. The rest of my comments are optional as they could be effected later. Andrei
Re: What Makes A Programming Language Good
Le 19/01/2011 20:20, Nick Sabalausky a écrit : nedbrek nedb...@yahoo.com wrote in message news:ih6o0g$2geu$1...@digitalmars.com... Vladimir Panteleev vladi...@thecybershadow.net wrote in message news:op.vpjlwrletuz...@cybershadow.mshome.net... On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings ah0801...@yahoo.com wrote: On 1/19/2011 12:50 AM, Vladimir Panteleev wrote: Actually, you're probably right here. To my knowledge, there are only two build tools that take advantage of the -deps compiler option - rdmd and xfbuild. Older ones were forced to parse the source files - rebuild even used DMD's frontend for that. There's also a relatively new tool (dbuild oslt?) which generates makefiles. Can someone tell me the corner case that requires a build tool to parse the whole source file? My make helper is awk, it just looks for the import and strips out the needed info... Just as a few examples: mixin(import foo.bar;); // or enum a = import ; enum b = foo.; enum c = bar;; mixin(a~b~c); // or static if(/+some fancy condition here+/) import foo.bar; This is exactly the reason why the build system must be included in the compiler and not in external tools.
Re: Decision on container design
On 01/29/2011 12:44 PM, Jim wrote: bearophile Wrote: Simon Buerger: * container should be named with respect to their use, not the implementation. HashSet is a bad name, because the user shouldnt care about the implemenation. This is good for a language like Python, or even Java, but for a system language I want to know the algorithms I'm using under the hood. So I am not sure. There could be an interface named Set and various implementations of it, e.g. HashSet. I think this would be a good principle in general for all abstract collection types. Thus approach has a few advantages but a lot of serious issues. I decided to not define a hierarchy for std.container. Andrei
Re: Decision on container design
On 01/29/2011 01:29 PM, dsimcha wrote: http://www.dsource.org/projects/aa/browser/trunk/randAA/randaasealed.d On 1/29/2011 2:18 PM, Andrei Alexandrescu wrote: On 01/29/2011 12:54 PM, dsimcha wrote: Also, I like reference counting for huge arrays/AAs enough that I submitted a ref counted hash table implementation to the Phobos list for review, which noone seemed to notice. Please comment. Where is it? Andrei Well to create a proposal you'd need to generate the documentation and put it somewhere and write a note to this group motivating the poposal and asking for a review manager. Andrei
Re: Suggestion: New D front page
I wrote: I started writing this site in D http://arsdnet.net/d-web-site/ I continued with this a little more, and I'm starting to like it now. I added a relative time thing to the commits, for example, 1 day ago on druntime. This way, a visitor can tell at-a-glance that D is actively developed. My compile and run thing works. I probably won't keep it for security reasons, but it does some cool things like support cgi output, (some) third party libraries, and demangled error output. The code that auto-fills could be a rotation of small example programs, or it might have some little tabs above it (or something) to load up a bunch of examples on demand. Anyone have ideas on how to best implement the announcements and featured projects thing? I figure the featured projects could be a manually maintained list, from which it picks some at random to show. Announcements seems like the best would be to pull recent thread titles off the announce newsgroup, but I don't know how to make that actually happen.
Re: What Makes A Programming Language Good
Le 18/01/2011 13:01, Vladimir Panteleev a écrit : On Tue, 18 Jan 2011 13:27:56 +0200, bearophile bearophileh...@lycos.com wrote: Vladimir Panteleev: It also demotivates and alienates programmers. I don't believe so. I've never seen any C++ programmer who has worked on other languages like Java complain about the Java naming conventions or the obligatory one class = one file. Never. In the contrary, I believe most of them, when going back to C++, try to follow the same conventions as much as possible.
Re: structs vs classes
AFAIR scope classes are to be banished from the language. There's emplace instead. std.typecons' scoped() is to be used.
Re: structs vs classes
Patrick Kreft patrick_kr...@gmx.net wrote: On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński j...@ask.me wrote: Jim napisał: I'm only discussing the heap/stack difference. Classes with value semantics would be prone to the slicing problem. That is because of the type system not classes or value semantic cause of that. Really? How would I go about stuffing a 16-byte class instance into the 8 bytes allocated on the stack, anyway? -- Simen
Re: Decision on container design
I've uploaded the documentation to http://cis.jhu.edu/~dsimcha/randaasealed.html and mentioned it again on the mailing list. The documentation is pretty sparse because interface-wise it's just a standard hash table. More generally, though, are we still interested in sealed/ref counted containers? On 1/29/2011 2:52 PM, Andrei Alexandrescu wrote: On 01/29/2011 01:29 PM, dsimcha wrote: http://www.dsource.org/projects/aa/browser/trunk/randAA/randaasealed.d On 1/29/2011 2:18 PM, Andrei Alexandrescu wrote: On 01/29/2011 12:54 PM, dsimcha wrote: Also, I like reference counting for huge arrays/AAs enough that I submitted a ref counted hash table implementation to the Phobos list for review, which noone seemed to notice. Please comment. Where is it? Andrei Well to create a proposal you'd need to generate the documentation and put it somewhere and write a note to this group motivating the poposal and asking for a review manager. Andrei
Possible bug in std.algorithm.map
Hi!
Just read Andrei Alexandrescu's new book, and I'm starting to
experiment with using D in my algorithms research. Loved the book, and
I'm loving the language so far :D
I just hit a snag, though ... I was doing something simple, for which
my prototype code (in Python) was
d, u = max((D(u,v), v) for v in V)
I first started writing it explicitly with loops, but it got a bit too
verbose for my taste. Thought I'd use map and reduce, perhaps
(although I'm still not sure if that's practical, as I'm reducing with
max, but I'd like the argmax as well...).
Anyway -- while using attempting to use map, I suddenly got a
segfault. As I hadn't really done any crazy stuff with pointers, or
circumvented the bounds checks or the like, I was a bit surprised. I
have now boiled things down to the following little program:
import std.algorithm;
void f() {
auto x = 0;
double g(int z) { // Alt. 1: return int
auto y = x; // Alt. 2: remove this
return 0;
}
auto seq = [1, 2, 3];
auto res = map!(g)(seq);
}
void main() {
f();
}
When I compile and run this (dmd 2.051, OS X 10.5.8), I get a
segmentation fault.
Oddly enough, if I *either* change the return type to int *or* remove
the y = x line, things work just fine.
Am I correct in assuming this is a bug?
--
Magnus Lie Hetland
http://hetland.org
Re: Suggestion: New D front page
Adam D. Ruppe, quoting: I started writing this site in D http://arsdnet.net/d-web-site/ - The vertical alignment of the D and language are not right. - For the Compile and run button a Run button is enough, on the right. It may use the ideone API, but it uses an old D2 compiler... - The Hello World in D is ugly. It's an unnecessary huge program. People want to see very little programs that do a lot, not very large programs that do nearly nothing. So I suggest to replace it with something much better. - I suggest to align the line of links that's at the top on the right. And I suggest to replace the large | signs between them with something shorter, like a simple | char. - I suggest to swap the place of Getting started and Zen of D. Or maybe to swap Getting started and the little Run code window. - I suggest to replace the phrases written in the D zen with a more correct D Zen. D is not Higher level C, and the unfinished implementation for dotnet shows that no all D implementations will be native, and so on. Bye, bearophile
Re: Possible bug in std.algorithm.map
Magnus Lie Hetland wrote:
Hi!
Just read Andrei Alexandrescu's new book, and I'm starting to experiment
with using D in my algorithms research. Loved the book, and I'm loving
the language so far :D
I just hit a snag, though ... I was doing something simple, for which my
prototype code (in Python) was
d, u = max((D(u,v), v) for v in V)
I first started writing it explicitly with loops, but it got a bit too
verbose for my taste. Thought I'd use map and reduce, perhaps (although
I'm still not sure if that's practical, as I'm reducing with max, but
I'd like the argmax as well...).
Anyway -- while using attempting to use map, I suddenly got a segfault.
As I hadn't really done any crazy stuff with pointers, or circumvented
the bounds checks or the like, I was a bit surprised. I have now boiled
things down to the following little program:
import std.algorithm;
void f() {
auto x = 0;
double g(int z) { // Alt. 1: return int
auto y = x; // Alt. 2: remove this
return 0;
}
auto seq = [1, 2, 3];
auto res = map!(g)(seq);
}
void main() {
f();
}
When I compile and run this (dmd 2.051, OS X 10.5.8), I get a
segmentation fault.
Oddly enough, if I *either* change the return type to int *or* remove
the y = x line, things work just fine.
Am I correct in assuming this is a bug?
Yes. Sounds like bug 5064.
http://d.puremagic.com/issues/show_bug.cgi?id=5064
It's currently #8 on my list of most important bugs to fix in DMD.
Re: Suggestion: New D front page
bearophile: - The vertical alignment of the D and language are not right. hahaha, you sound like the designers I work with. I just spent a minute tweaking, though details like that can easily be changed later. I'm implementing the announcement reader now. I'm tempted to just write a full replacement for that awful web news program while I'm at it too! It may use the ideone API, but it uses an old D2 compiler... I think we need more control than it offers, to stay up-to-date and maybe offer other little fixes (like I did here). It would probably be best to set up a dedicated VM or something somewhere that's expendable so if security is compromised, it doesn't hurt anything. The Hello World in D is ugly. It's an unnecessary huge program. [snip other content ideas] All content is placeholders, like in the OP's image: http://digitalpoetry.se/D%20website/D%20overview%20design.png I changed the program though because I wanted to test my sandbox environment with something a little more interesting than hello world :) I like pretty pictures. I agree with you that it could use some tweaks, but I don't have any opinion on the specifics.
Re: What Makes A Programming Language Good
Am 29.01.2011 21:21, schrieb el muchacho: Le 18/01/2011 13:01, Vladimir Panteleev a écrit : On Tue, 18 Jan 2011 13:27:56 +0200, bearophile bearophileh...@lycos.com wrote: Vladimir Panteleev: It also demotivates and alienates programmers. I don't believe so. I've never seen any C++ programmer who has worked on other languages like Java complain about the Java naming conventions or the obligatory one class = one file. Never. In the contrary, I believe most of them, when going back to C++, try to follow the same conventions as much as possible. I often find one class = one file annoying. I haven't done much with C++, but some stuff with Java and D1. I mostly agree with javas naming conventions, though. Cheers, - Daniel
Re: Suggestion: New D front page
Adam D. Ruppe: hahaha, you sound like the designers I work with. I just spent a minute tweaking, though details like that can easily be changed later. You are right, I am silly, sorry. Regarding the Commits section, in this design they are very public, on the front page, so their text needs to be good enough :-) Bye, bearophile
Re: What Makes A Programming Language Good
Daniel Gibson Wrote: Am 29.01.2011 21:21, schrieb el muchacho: Le 18/01/2011 13:01, Vladimir Panteleev a écrit : On Tue, 18 Jan 2011 13:27:56 +0200, bearophile bearophileh...@lycos.com wrote: Vladimir Panteleev: It also demotivates and alienates programmers. I don't believe so. I've never seen any C++ programmer who has worked on other languages like Java complain about the Java naming conventions or the obligatory one class = one file. Never. In the contrary, I believe most of them, when going back to C++, try to follow the same conventions as much as possible. I often find one class = one file annoying. I haven't done much with C++, but some stuff with Java and D1. I mostly agree with javas naming conventions, though. Cheers, - Daniel I just wanted to remind that the accurate Java rule was one _public_ class per file. You can have more than one class in a file as long as only one is declared public. I dunno about your experience but mine was that this is not a problem in practice, at least not for me. As usually said bout this kind of things, YMMV.
Re: structs vs classes
On 29/01/11 9:36 PM, Simen kjaeraas wrote: Patrick Kreft patrick_kr...@gmx.net wrote: On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński j...@ask.me wrote: Jim napisał: I'm only discussing the heap/stack difference. Classes with value semantics would be prone to the slicing problem. That is because of the type system not classes or value semantic cause of that. Really? How would I go about stuffing a 16-byte class instance into the 8 bytes allocated on the stack, anyway? I believe his point is that you can't, and the type system shouldn't allow it (as it does in C++).
Re: structs vs classes
On Sun, 30 Jan 2011 00:16:20 +0100, Peter Alexander peter.alexander...@gmail.com wrote: On 29/01/11 9:36 PM, Simen kjaeraas wrote: Patrick Kreft patrick_kr...@gmx.net wrote: On Sat, 29 Jan 2011 15:45:41 +0100, Tomek Sowiński j...@ask.me wrote: Jim napisał: I'm only discussing the heap/stack difference. Classes with value semantics would be prone to the slicing problem. That is because of the type system not classes or value semantic cause of that. Really? How would I go about stuffing a 16-byte class instance into the 8 bytes allocated on the stack, anyway? I believe his point is that you can't, and the type system shouldn't allow it (as it does in C++). Well not exactly, i mean it's true for D and all languages, which use nominal type system, but it's not true for all languages. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: Suggestion: New D front page
On 01/29/2011 02:14 PM, Adam D. Ruppe wrote: I wrote: I started writing this site in D http://arsdnet.net/d-web-site/ I continued with this a little more, and I'm starting to like it now. I love how errors propagate from D to HTML, just like from PHP. Here's what I just got: std.exception.ErrnoException@std/stdio.d(423): Could not close file `news.digitalmars.com:119' (Illegal seek) /var/www/htdocs/d-web-site/site(bool std.exception.errnoEnforce!(bool, std/stdio.da, 423).errnoEnforce(bool, lazy immutable(char)[])) [0x80ca459] /var/www/htdocs/d-web-site/site(void std.stdio.File.close()) [0x80c9453] /var/www/htdocs/d-web-site/site(void std.stdio.File.__dtor()) [0x80c91db] /var/www/htdocs/d-web-site/site(site[] site.getAnnouncements()) [0x8097796] /var/www/htdocs/d-web-site/site(_D4site16addAnnouncementsFC4arsd3dom7ElementZv+0x17) [0x809639b] /var/www/htdocs/d-web-site/site(_D4site4siteFC4arsd3cgi3CgiZv+0x91) [0x80964d5] /var/www/htdocs/d-web-site/site(_Dmain+0x2c) [0x8096560] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8bb6] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8b10] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8bfa] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8b10] /var/www/htdocs/d-web-site/site(main+0x96) [0x80b8ab6] /lib/libc.so.6(__libc_start_main+0xe6) [0xf75cab86] /var/www/htdocs/d-web-site/site() [0x8095c41] std.exception.ErrnoException@/home/me/d/dmd2/linux/bin/../../src/phobos/std/stdio.d(671): Could not flush file `news.digitalmars.com:119' (Illegal seek) /var/www/htdocs/d-web-site/site(bool std.exception.errnoEnforce!(bool, /home/me/d/dmd2/linux/bin/../../src/phobos/std/stdio.da, 671).errnoEnforce(bool, lazy immutable(char)[])) [0x80a7613] /var/www/htdocs/d-web-site/site(void std.stdio.File.writeln!(immutable(char)[]).writeln(immutable(char)[])) [0x80992aa] /var/www/htdocs/d-web-site/site(site[] site.getAnnouncements()) [0x8097785] /var/www/htdocs/d-web-site/site(_D4site16addAnnouncementsFC4arsd3dom7ElementZv+0x17) [0x809639b] /var/www/htdocs/d-web-site/site(_D4site4siteFC4arsd3cgi3CgiZv+0x91) [0x80964d5] /var/www/htdocs/d-web-site/site(_Dmain+0x2c) [0x8096560] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8bb6] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8b10] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8bfa] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8b10] /var/www/htdocs/d-web-site/site(main+0x96) [0x80b8ab6] /lib/libc.so.6(__libc_start_main+0xe6) [0xf75cab86] /var/www/htdocs/d-web-site/site() [0x8095c41] core.exception.AssertError@site.d(343): 230 New news follows [110122 233017 GMT] /var/www/htdocs/d-web-site/site(onAssertErrorMsg+0x34) [0x80ccaf4] /var/www/htdocs/d-web-site/site(_d_assert_msg+0x18) [0x80b89a8] /var/www/htdocs/d-web-site/site(site[] site.getAnnouncements()) [0x8097455] /var/www/htdocs/d-web-site/site(_D4site16addAnnouncementsFC4arsd3dom7ElementZv+0x17) [0x809639b] /var/www/htdocs/d-web-site/site(_D4site4siteFC4arsd3cgi3CgiZv+0x91) [0x80964d5] /var/www/htdocs/d-web-site/site(_Dmain+0x2c) [0x8096560] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8bb6] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8b10] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8bfa] /var/www/htdocs/d-web-site/site(extern (C) int rt.dmain2.main(int, char**)) [0x80b8b10] /var/www/htdocs/d-web-site/site(main+0x96) [0x80b8ab6] /lib/libc.so.6(__libc_start_main+0xe6) [0xf75cab86] /var/www/htdocs/d-web-site/site() [0x8095c41] Cache-Control: private, no-cache=set-cookie Expires: 0 Pragma: no-cache Content-Type: text/html; charset=utf-8 Andrei
Re: Suggestion: New D front page
Andrei Alexandrescu wrote: I love how errors propagate from D to HTML, just like from PHP. Yeah, a boring Internal Server Error would be hell to figure out what's going on, so it outputs the exception.toString. It can also be hooked to give a styled error screen too! But that's an interesting exception (I'm in the middle of writing a quick NNTP function to do the announcements). Looks like if there's still data in the read buffer, std.stdio.File tries to skip past it, but since this is a network stream, it can't. I'm just flushing the buffer before returning from the function. The site now loads again, now with automatic reading from digitalmars.D.announce!
Re: Suggestion: New D front page
On 1/29/2011 3:50 PM, Adam D. Ruppe wrote: Andrei Alexandrescu wrote: I love how errors propagate from D to HTML, just like from PHP. Yeah, a boring Internal Server Error would be hell to figure out what's going on, so it outputs the exception.toString. It can also be hooked to give a styled error screen too! Exposing those sorts of errors directly to users is easy and handy during the early stages, but really ought to just be in the website logs. Exceptions and other internal state leaks like that are both ugly and can potentially point to exploitable security issues. The site now loads again, now with automatic reading from digitalmars.D.announce! For a site with any traffic, placing load on a remote site like that is fairly rude. I suggest re-thinking that design before it causes problems. A periodic cron job that caches the data locally would be a good alternative. I realize this is a young project and it might not go anywhere, but it's usually easier to get off on the right foot than scramble to fix things later. My 2 cents, Brad
Re: Suggestion: New D front page
Here's a summary of what the code does: The compile and run box in the upper left runs DMD through my build.d program from last week (meaning you have access to whatever modules are in my repository and it demangles output). It also checks for programs outputting CGI protocol headers and forwards it to the browser. The example program there now uses this to output a PNG image to your browser. Moving down to Announcements, it pulls the thread titles of the five most newsgroup posts. It determines if a message is a thread by checking headers.indexOf(References: )... it isn't 100% accurate though. Anyone know of a better way? I'm an NNTP noob. The Commits pulls the most recent commits from DMD, druntime, and Phobos, then sorts by date and displays the most recent five. It beautifies the date... though my timezone code is evidently buggy... so you can see at a glance how active things are. Featured Projects is currently static html. I'm open to suggestions on how to automate that. And currently, at the bottom of the site, below the header, is a ddoc program output with syntax highlighting. There's a small bit of javascript that scans the file for those and adds an Edit button above it. If you click that, it puts it in a textarea and lets you compile and run it through the same service as used above. That script can be added to any ddoc page to make its code compilable. It needs to move to an isolated system for an actual launch.
Re: Suggestion: New D front page
Brad Roberts wrote: Exposing those sorts of errors directly to users is easy and handy during the early stages, but really ought to just be in the website logs. Right, that's why you can move it to use only stderr (which Apache automatically logs) with a simple recompile. For a site with any traffic, placing load on a remote site like that is fairly rude. It doesn't check every time. It loads from a cache file, but if the cache is outdated or not present, it checks the news server to get new news. if(cache exists cache.age nn) return cache; else ask the server for new news since the time the cache was last modified write the new result to the cache
Re: Suggestion: New D front page
On 1/29/2011 4:11 PM, Adam D. Ruppe wrote: Brad Roberts wrote: Exposing those sorts of errors directly to users is easy and handy during the early stages, but really ought to just be in the website logs. Right, that's why you can move it to use only stderr (which Apache automatically logs) with a simple recompile. For a site with any traffic, placing load on a remote site like that is fairly rude. It doesn't check every time. It loads from a cache file, but if the cache is outdated or not present, it checks the news server to get new news. if(cache exists cache.age nn) return cache; else ask the server for new news since the time the cache was last modified write the new result to the cache Good answers. I'd pull the updating out of the user stream into a separate job so that any delays or networking issues don't impact the user experience. But you've covered the bigger issue. Sorry to harp on security issues, but what are you doing to protect yourself from those compile and run arbitrary code boxes? What happens if someone writes and executes the equivalent of rm -rf /?
Re: Suggestion: New D front page
Sorry to harp on security issues, but what are you doing to protect yourself from those compile and run arbitrary code boxes? It runs a separate process which is suid'd to a single purpose restricted user that only has access to one directory and a number of ulimits in force. So they could in theory write evil things, but the operating system won't let it gain much ground. I'm currently setting up a separate virtual machine on a different domain to handle that, so even if they broke it, the system is completely expendable anyway. Problems with this would be if someone wanted to set up a network spammer or a CPU eater. Perhaps a cron job that loops around killing processes would help with that. I need to think about it some more. Redirecting the user to ideone might end up being the best solution (or dropping the feature) but I want to shoot for something higher first.
Internal error: backend\cod1.c 1895 when trying to build DMD/Druntime/Phobos from source
I'm trying to build DMD, Druntime and Phobos from source. The resulting dmd.exe fails to compile Phobos with the error Internal error: backend\cod1.c 1895. It seems to be dependent on my environment... I tried building it in a virtual machine, and it worked fine. Does anyone have any idea what might cause it? Does the ICE count as a compiler bug? -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Suggestion: New D front page
Brad Roberts wrote: I'd pull the updating out of the user stream into a separate job so that any delays or networking issues don't impact the user experience. I moved it to a background process (spawned and killed on demand, simple one line change in the source). I dislike cron jobs since they run even if you don't need them and need special setup (editing the crontab or whatever). A cache updater and a background process gets the job done just as well without those downsides. But, it occurs to me that this entire website could be on a cron job, updated once or twice a day, if we move the platform detection to the client side. It's not like the content is truely dynamic per visit or different for various people (even if it had random code samples or projects, that could be updated infrequently and still be good enough). It just periodically updates its content - exactly what a cron job putting out plain HTML would do. That might be the way to go. It fits in with the rest of the site being basic html too, so Walter might prefer it.
Re: Suggestion: New D front page
Russel Winder rus...@russel.org.uk wrote in message news:mailman.1036.1296316027.4748.digitalmar...@puremagic.com... I absolutely abhor high contrast websites, i.e. ones with white backgrounds, (take note Google) and navigate away from them as soon as possible, or even immediately. I much prefer muted medium contrast websites. It is not just taste, though that is much of it, it is also an issue of some people having vision issues. Or an issue of people having their monitor's brightness/contrast cranked up too high? ;) Not that I'm disagreeing with you, though.
Re: Decision on container design
On Friday 28 January 2011 10:31:58 Andrei Alexandrescu wrote: Today after work I plan to start making one pass through std.container. After having thought of things for a long time, my conclusions are as follows: 1. Containers will be classes. 2. Most of the methods in existing containers will be final. It's up to the container to make a method final or not. 3. Containers and their ranges decide whether they give away references to their objects. Sealing is a great idea but it makes everybody's life too complicated. I'll defer sealing to future improvements in the language and/or the reflection subsystem. 4. Containers will assume that objects are cheap to copy so they won't worry about moving primitives. Any showstoppers, please share. Overall, I think definitely support this approach. I definitely think that containers should be reference types, and I'm not sure that I care much whether they end up being structs or classes. My one concern would be the ability to inline the container's function calls, and marking them as final fixes that problem. I'm not sure that I know enough about the sealing issue to comment on it, but if what we're doing doesn't preclude having it later, then that sounds like it's a good compromise. And I definitely think that make it so that containers don't have to worry about moving primitives is the way to go. So, I'm essentially 100% behind this, and I don't see any real issues with it. Containers is one of the places that Phobos is generally behind on and which really needs to be taken care if we really want people to be using D and Phobos. So, it's great to see that progress is being made with regards to containers. - Jonathan M Davis
Re: structs vs classes
On Saturday 29 January 2011 07:11:41 Jim wrote:
biozic Wrote:
Le 29/01/11 14:43, Jim a écrit :
I'm a bit troubled with the class/struct dichotomy. I would prefer them
both to use the same keyword. Heap/stack allocation could be specified
during instantiation instead. Why? Now you need to choose one over the
other. Not even C++ has this limitation.
Think about containers for example, should they be classes or structs?
Do you want them on the stack or on the heap?
I guess it's possible to define the entire container as a mixin now.
That would let you have both heap and stack containers share
definition, but generally I think that the dichotomy should be
abolished.
The difference between class and struct in D is more than heap or stack
allocation. Having a common keyword for them would unwisely mask their
fundamental differences (inheritance/polymorphism, reference/value
semantics, etc.).
Perhaps the suggestion is in fact one that has already been made but for
which I can't remember the conclusion: how about abandoning 'new' in
favor of more specific keywords/library templates that control whether
the instantiation occur on the heap or on the stack?
Yes, abandoning new if it would help. Objects on the heap could be managed
by different garbage collectors (or with different settings, mark-sweep,
precise/conservative, reference-counting, etc.).
I don't want to have to change the definition of the type. The
instantiation is a separate concern to the implementation. It should be up
to the user of a type to decide whether to allocate it on the stack or the
heap and so on.
The compiler should be intelligent enough to see whether the class is
derived or not and do its optmisations accordingly.
structs are value types. classes are reference types. That can drastically
change how they are designed and used. Passing something to
void func(A a) {/*...*/}
is going to have _vastly_ different behavior when dealing with value types than
when dealing with reference types. For a value type, it'll be a copy. For a
reference type, it's just copying the reference, so the function is free to
change the state of the object that you passed in. How on earth would the
compiler decide which behavior is correct? It can't. That's up to the
programmer.
The differences between structs and classes are critical. It's _not_ just a
question of optimization. And the compiler can't generally make an optimization
choice based on whether a type is derived or not anyway, because it also needs
to know whether a type is derivide from _it_, and it can't know that at compile
time thanks to the separate compilation model. Classes don't know about what
types are derived from them, and the derived types could be in entirely
separate
libraries - separate shared libraries even (assuming that shared libraries are
properly supported, which is on the TODO list).
C# also chose to make structs and classes separate. It's a solide design
decision. In many, many cases, how a classes is designed and functions is
affected by how it is instantiated. It can make a big difference whether a type
is
intended to be instantiated on the stack or on the heap.
structs are value types without inheritance or polymorphism. They support RAII.
classes are reference types with inheritance and polymorphism. They don't
really
support RAII (they have destructors, but there's no guarantee that they'll ever
be called, and there are various limitation on their destructors).
They are distinctly different. It was a mistake for C++ to have polymorphic
types
which could go on the stack. It causes slicing and ultimately doesn't make
sense. If you program in C++, you learn to deal with it and program in a way
that it doesn't cause problems, but it's still a problematic design choice.
Separating user-defined value and reference types makes things considerably
cleaner and safer. C# did and and D does it. Java didn't do it, but that's
because it doesn't _have_ user-defined value types. C++ is the only language
that
I know of which tries to conflate user-defined value and reference types.
It may take some getting used to, but D's choice of separating structs and
classes is a solid one.
- Jonathan M davis
Re: review for unittests
On Saturday 29 January 2011 11:46:55 Andrei Alexandrescu wrote: I made one more pass through the unittests library and it looks fine, but I still find it wanting. Overall: * From too few examples now it has too many! The fine line is somewhere in between (I'd say on the short side). I complained about the initial documentation because the example were meaningless (e.g. they used names that weren't defined. The current iteration of the library gives so many examples it's patronizing. Yes, if you give the list of operators supported, you don't need to give an example of each! We're not oligophrenes over here. * To add insult to injury, examples have a double-spacing that is a bit much. I thought that I'd removed all of that. Apparently not. * The code has a lot of lines beyond 80 characters. 80 characters should be plenty to write good code, and makes for readable code that doesn't need to occupy one's entire screen. I wish I could somehow convince everybody to not complain, not debate, and not show me the old style guide. Let's just write 80-columns code. That includes documentation. Please. Let's. * Even examples are sometimes too wide - some don't fit in my browser unless I enlarge it considerably. You mean 80 lines of code in the examples or in the actual code? I'm fine with 80 columns for examples, but I'll go insane if we start requiring 80 columns for normal code. That starts getting restrictive and ugly _really_ fast. You're quickly forced to put the next part of a statement on the next line just because you're hitting the 80 character limit instead of properly lining things up, and it makes them much harder to read. As for the documentation, I made sure that the examples fit in the grey code boxes, and that's what I was aiming for. If that doesn't do it and restricting them to 80 columns does, then I'll do that. * I don't mean to belittle the effort, but the documentation needs one more pass for typos etc. I wouldn't mention this if I hadn't noticed Jonathan is otherwise a perfect speller and a good writer. So, it's Generally speaking not Generally-speaking, given set not give set... and that's just the first line. Eliminate all flowery: there's no need for generally speaking and in essence particularly etc. etc. etc. * For inline code use $(D ) not anything else I'll make another pass then. I obviously missed some stuff. Feel free to point out spelling mistakes and the like. If they're there, it's pretty much a guarantee that it's because I missed them than because I didn't know better (though for some reason, I did get it in my head that it was generally-speaking rather than generally speaking; it does appear that you're correct however). * I appreciate the date-based examples but I'd rather stick with one focus at a time. I used them so that I could give examples involving functions throwing exceptions without having to create types or functions in the examples which did that. * There's got to be too much of a good thing. The massive unittests, the lavish waste of vertical space (import with commas, anyone?) and the documentation make adding four simple concepts a 1887 lines deal. I guess that's borderline okay but I am increasingly hawkish about massive additions of small functionality to Phobos. I confess that I hate having imports put together in one statement just like I hate declaring multiple variables on one line. I think that it harms readability and maintainability. But if you insist on putting imports on a single line in Phobos, then I can do that. As for the unit tests, what do you want me to do? They verify that the functions work correctly. They're thorough. That naturally makes them longer rather than shorter. You pretty much either get short unit tests or thorough unit tests. I tend to err on the side of thorough rather than short. * The documentation for the mock-up assertPred could be moved up to the module documentation, which has the advantage that it avoids any self-explaining: There is further documentation for each version below (this particular version of the function doesn't actually exist - it's here so that there's a good spot to put documentation for the function as a whole). Why would anyone need to absorb that kind of information in order to use four simple concepts? I'm all for finding ways to better organize the assertPred documentation. The general problem with it is that while it's quite simple to use, it has so many variations that it takes a fair bit of explaining. I'm not about to claim that it currently does it the best way that it could though. My vote is in favor to adopting this library, contingent upon (a) making a spelling and correctness pass and (b) giving the documentation a thorough haircut. The rest of my comments are optional as they could be effected later. I'll make another pass at at the documentation and see if I can hit a better balance between too
Re: Decision on container design
On Saturday 29 January 2011 09:09:00 Simon Buerger wrote: * container should be named with respect to their use, not the implementation. HashSet is a bad name, because the user shouldnt care about the implemenation. It was decided previously that containers in std.container would specifically be named based on the type of data structure that they are rather than what they're used for. Hence why the newest container to std.container is called RedBlackTree. If you want to call it TreeSet or something similar, then all you have to do is alias it. So, it's easy to get names based on usage if that's what you want, but that's not the naming scheme that std.container is using. - Jonathan M Davis
Does anyone know 64 bit asm?
http://stackoverflow.com/questions/4840957/does-the-rex-b-override-work-with-the-movss-instruction
Re: Smartphones and D
On Saturday 29 January 2011 21:45:33 jim_g wrote: Hello I'm currently doing business with 4 commercial applications on Android 2.1+ and iPhone 3GS+. One of the current problems is that we're facing the limits of performance especially when developing Java which is interpreted on the oldest hardware. Thanks to reddit I read about D recently and it seems to hit the head of the nail squarely. I've used to think that more performance means less power in the language when thinking in ways of simplicity (easy to read), high level language features (nameless functions) and so on. BUT D has it all in a nice package and solves all these issues. My question is, how well does D support ARMv6 and ARMv7? I'd like to make full use of auto-vectorization and inlining when doing foreach loops, iterators with inline predicates, and array operations. Our problem with C on ARM is that many compilers are still far from good. We wouldn't want to buy a commercial compiler unless it's really worth its salt. Reading this newsgroup revealed that D uses some kind of thing called 'lowerings' for optimizing high level features. Does this avoid all these complex bugs? Another question is, does D have any tutorials for building stuff on ARM? Any Android/iOS bindings anywhere? Has anyone done any Android/iPhone development in D? Would you recommend D instead of C/C++ for these platforms? If not, how long will it take before D beats C/C++ on these platforms? How I see it is there's not much time left to earn big money on these. Some popular applications already become (adware) free because of piracy and competition. gdc or LDC might be able to build for ARM. I don't know. But dmd is x86 only (with x86_64 on the way). So, at the moment, you're not going to be able to build for ARM using dmd. I suspect that gdc can do it, since it's using gcc for its backend, but I don't know. There's probably a good chance that dmd will support ARM _eventually_ - as long as there's sufficient demand for it - but I doubt that it will any time soon. I expect that there are too many other things that need to be done for it to be a high priority at the moment. - Jonathan M Davis
Smartphones and D
Hello I'm currently doing business with 4 commercial applications on Android 2.1+ and iPhone 3GS+. One of the current problems is that we're facing the limits of performance especially when developing Java which is interpreted on the oldest hardware. Thanks to reddit I read about D recently and it seems to hit the head of the nail squarely. I've used to think that more performance means less power in the language when thinking in ways of simplicity (easy to read), high level language features (nameless functions) and so on. BUT D has it all in a nice package and solves all these issues. My question is, how well does D support ARMv6 and ARMv7? I'd like to make full use of auto-vectorization and inlining when doing foreach loops, iterators with inline predicates, and array operations. Our problem with C on ARM is that many compilers are still far from good. We wouldn't want to buy a commercial compiler unless it's really worth its salt. Reading this newsgroup revealed that D uses some kind of thing called 'lowerings' for optimizing high level features. Does this avoid all these complex bugs? Another question is, does D have any tutorials for building stuff on ARM? Any Android/iOS bindings anywhere? Has anyone done any Android/iPhone development in D? Would you recommend D instead of C/C++ for these platforms? If not, how long will it take before D beats C/C++ on these platforms? How I see it is there's not much time left to earn big money on these. Some popular applications already become (adware) free because of piracy and competition. Cheers = jim =
Re: Is D not-for-profit or not?!
On Saturday 29 January 2011 21:41:28 Jack wrote: Tell! No trolling please. D is a programming language. There's nothing about D which would be for profit or not for profit. You don't sell a programming language. The compilers could be for profit if they were sold, but they aren't. All of them are open source, with the only snag being that the license for dmd's backend is such that you can see the source but not copy it and change it and whatnot. The frontend is entirely open source however, and both gdc and LDC are entirely open source. Regardless, they're all free to download and use. You can probably buy enterprise support for dmd from Digital Mars like you can with dmc, but I don't know anything about that, and that's buying support not software. It really doesn't make sense to ask whether D is for profit or not. Programming languages aren't for profit. Their tools may be, but you don't buy or rent programming languages, so asking whether D is for profit or not really doesn't make any sense. - Jonathan M Davis
Re: review for unittests
On 01/29/2011 09:48 PM, Jonathan M Davis wrote: You mean 80 lines of code in the examples or in the actual code? I'm fine with 80 columns for examples, but I'll go insane if we start requiring 80 columns for normal code. That starts getting restrictive and ugly _really_ fast. Yes, once you go beyond 80 columns. You're quickly forced to put the next part of a statement on the next line just because you're hitting the 80 character limit instead of properly lining things up, and it makes them much harder to read. When Gutenberg built the first press, the resolution and the coarseness of the paper forced him to make the sheets pretty large. Since then the resolution of printing has increased amazingly, but people quickly figured out that reading is seriously impaired if the layout has more than about ten words per row of text. So in the hundreds of years that people have had available for improving printing media, the ten words pattern has stayed put. It's a human constant. Such a measure definitely to code, too. 80 columns should be enough for writing and reading meaningful code. Lines that go significantly beyond that limit have an intrinsic readability problem. As for the documentation, I made sure that the examples fit in the grey code boxes, and that's what I was aiming for. If that doesn't do it and restricting them to 80 columns does, then I'll do that. They don't fit on my screen. I'll make another pass at at the documentation and see if I can hit a better balance between too little explanation and not enough. In fact, I think that I'll just merge it into std.exception (since you seemed to think that that would be the place to put it) and post what it would then look like once put into Phobos (since doing stuff like putting assertPred documentation in the module comment would affect the module as a whole and std.exception obviously already has stuff in it). I'll take care of that and get it up within the next few days. Yes, please integrate with std.exception. For the documentation: all you need is take your initial examples and make them compilable. Otherwise they were perfect. Thanks, Andrei
Re: Smartphones and D
jim_g Wrote: Jonathan M Davis Wrote: On Saturday 29 January 2011 21:45:33 jim_g wrote: Hello I'm currently doing business with 4 commercial applications on Android 2.1+ and iPhone 3GS+. One of the current problems is that we're facing the limits of performance especially when developing Java which is interpreted on the oldest hardware. Thanks to reddit I read about D recently and it seems to hit the head of the nail squarely. I've used to think that more performance means less power in the language when thinking in ways of simplicity (easy to read), high level language features (nameless functions) and so on. BUT D has it all in a nice package and solves all these issues. My question is, how well does D support ARMv6 and ARMv7? I'd like to make full use of auto-vectorization and inlining when doing foreach loops, iterators with inline predicates, and array operations. Our problem with C on ARM is that many compilers are still far from good. We wouldn't want to buy a commercial compiler unless it's really worth its salt. Reading this newsgroup revealed that D uses some kind of thing called 'lowerings' for optimizing high level features. Does this avoid all these complex bugs? Another question is, does D have any tutorials for building stuff on ARM? Any Android/iOS bindings anywhere? Has anyone done any Android/iPhone development in D? Would you recommend D instead of C/C++ for these platforms? If not, how long will it take before D beats C/C++ on these platforms? How I see it is there's not much time left to earn big money on these. Some popular applications already become (adware) free because of piracy and competition. gdc or LDC might be able to build for ARM. I don't know. But dmd is x86 only (with x86_64 on the way). So, at the moment, you're not going to be able to build for ARM using dmd. I suspect that gdc can do it, since it's using gcc for its backend, but I don't know. There's probably a good chance that dmd will support ARM _eventually_ - as long as there's sufficient demand for it - but I doubt that it will any time soon. I expect that there are too many other things that need to be done for it to be a high priority at the moment. - Jonathan M Davis Thanks for the reply. In my opinion this is a huge shame. The x86 market is oversaturated with languages, but if you're doing something exotic, there's only C/C++. Btw ARM isn't especially exotic. Most portable devices except laptops have used it for years. While there are many language platforms for smartphones, for example Java, C#, Obj-C, C, C++, JavaScript, and Python, none of these are especially high level and performance oriented at the same time. What I tried to say is, in my opinion, a language with only a half or a quarter of D's improvements over C++ would be more successful on smartphone/tablet platforms than yet another x86 oriented language, no matter how good. The killer feature is to be in the right place and the right time. = jim =
Re: Smartphones and D
Jonathan M Davis Wrote: On Saturday 29 January 2011 21:45:33 jim_g wrote: Hello I'm currently doing business with 4 commercial applications on Android 2.1+ and iPhone 3GS+. One of the current problems is that we're facing the limits of performance especially when developing Java which is interpreted on the oldest hardware. Thanks to reddit I read about D recently and it seems to hit the head of the nail squarely. I've used to think that more performance means less power in the language when thinking in ways of simplicity (easy to read), high level language features (nameless functions) and so on. BUT D has it all in a nice package and solves all these issues. My question is, how well does D support ARMv6 and ARMv7? I'd like to make full use of auto-vectorization and inlining when doing foreach loops, iterators with inline predicates, and array operations. Our problem with C on ARM is that many compilers are still far from good. We wouldn't want to buy a commercial compiler unless it's really worth its salt. Reading this newsgroup revealed that D uses some kind of thing called 'lowerings' for optimizing high level features. Does this avoid all these complex bugs? Another question is, does D have any tutorials for building stuff on ARM? Any Android/iOS bindings anywhere? Has anyone done any Android/iPhone development in D? Would you recommend D instead of C/C++ for these platforms? If not, how long will it take before D beats C/C++ on these platforms? How I see it is there's not much time left to earn big money on these. Some popular applications already become (adware) free because of piracy and competition. gdc or LDC might be able to build for ARM. I don't know. But dmd is x86 only (with x86_64 on the way). So, at the moment, you're not going to be able to build for ARM using dmd. I suspect that gdc can do it, since it's using gcc for its backend, but I don't know. There's probably a good chance that dmd will support ARM _eventually_ - as long as there's sufficient demand for it - but I doubt that it will any time soon. I expect that there are too many other things that need to be done for it to be a high priority at the moment. - Jonathan M Davis Thanks for the reply. In my opinion this is a huge shame. The x86 market is oversaturated with languages, but if you're doing something exotic, there's only C/C++. Btw ARM isn't especially exotic. Most portable devices except laptops have used it for years. While there are many language platforms for smartphones, for example Java, C#, Obj-C, C, C++, JavaScript, and Python, none of these are especially high level and performance oriented at the same time. = jim =
Is D not-for-profit or not?!
Tell!
Re: review for unittests
On Saturday 29 January 2011 22:10:29 Andrei Alexandrescu wrote: On 01/29/2011 09:48 PM, Jonathan M Davis wrote: You mean 80 lines of code in the examples or in the actual code? I'm fine with 80 columns for examples, but I'll go insane if we start requiring 80 columns for normal code. That starts getting restrictive and ugly _really_ fast. Yes, once you go beyond 80 columns. You're quickly forced to put the next part of a statement on the next line just because you're hitting the 80 character limit instead of properly lining things up, and it makes them much harder to read. When Gutenberg built the first press, the resolution and the coarseness of the paper forced him to make the sheets pretty large. Since then the resolution of printing has increased amazingly, but people quickly figured out that reading is seriously impaired if the layout has more than about ten words per row of text. So in the hundreds of years that people have had available for improving printing media, the ten words pattern has stayed put. It's a human constant. Such a measure definitely to code, too. 80 columns should be enough for writing and reading meaningful code. Lines that go significantly beyond that limit have an intrinsic readability problem. I'm afraid that we're going to disagree on this one completely. Restricting code to 80 columns makes formatting a mess. You start doing things like breaking the next line based on how close it is to 80 columns rather than where it would make sense to break it based on the statement itself. Often, you're forced to put the remainder of the line on the next line simply indented somewhat more than the previous line rather than indenting it far enough to line up paretheses and function arguments. I much prefer lines that look like auto a = func(replace(str, hello, world), 13 + max(b, c)); to auto a = func(replace(str, hello,world), 13 + max(b, c)); or auto a = func(replace(str, hello,world), 13 + max(b, c)); Formatting becomes a _big_ problem when you force 80 character lines - _especially_ if you use descriptive names for functions and variables. And if you allow for greater than 80 character lines, then lines that would 90 or 100 characters and look just fine can be left on one line without having to worry about formatting problems at all. The problem becomes particularly bad if you have code with multiple levels of scope. All of a sudden, your inner loop has to have all of its code take multiple lines just because it's indented far enough to be close to 80 characters. The _only_ reason I see to restrict the number of columns on a line like that is for printing code. If you make lines too long, they won't fit on paper. But they'll fit just fine on a computer screen at well beyond 80 columns. With gvim, a line with 80 columns takes up less than a third of my screen - and that's with stuff like line numbers being shown. Unless you're specifically restricting the size of your edit windown to 80 columns, I don't see why having more than 80 characters on a line would be a problem. And sure, you don't want lines getting to be 120 characters long and the like. There is a limit to how much it makes sense to put in a single statement. However, I have routinely found that when I've been restricted to 80 column lines, code becomes far harder to format properly, statements which really should be on one line are forced to be on multiple lines because they're a bit passed 80 characters, and the code is harder to read. I find that code is formatted much better when you're not strict about the length of lines and the like. You try and limit how long lines get, and you break them up on multiple lines when they start getting too long, but if you're strict about it, lines quickly become ill-formatted and harder to read. - Jonathan M Davis
Re: Does anyone know 64 bit asm?
Walter Bright wrote: http://stackoverflow.com/questions/4840957/does-the-rex-b-override-work-with-the-movss-instruction Never mind, I solved it.
Re: Possible bug in std.algorithm.map
On Sat, 29 Jan 2011 11:12:28 -0500, Magnus Lie Hetland m...@idi.ntnu.no
wrote:
Hi!
Just read Andrei Alexandrescu's new book, and I'm starting to experiment
with using D in my algorithms research. Loved the book, and I'm loving
the language so far :D
I just hit a snag, though ... I was doing something simple, for which my
prototype code (in Python) was
d, u = max((D(u,v), v) for v in V)
I first started writing it explicitly with loops, but it got a bit too
verbose for my taste. Thought I'd use map and reduce, perhaps (although
I'm still not sure if that's practical, as I'm reducing with max, but
I'd like the argmax as well...).
Anyway -- while using attempting to use map, I suddenly got a segfault.
As I hadn't really done any crazy stuff with pointers, or circumvented
the bounds checks or the like, I was a bit surprised. I have now boiled
things down to the following little program:
import std.algorithm;
void f() {
auto x = 0;
double g(int z) { // Alt. 1: return int
auto y = x; // Alt. 2: remove this
return 0;
}
auto seq = [1, 2, 3];
auto res = map!(g)(seq);
}
void main() {
f();
}
When I compile and run this (dmd 2.051, OS X 10.5.8), I get a
segmentation fault.
Oddly enough, if I *either* change the return type to int *or* remove
the y = x line, things work just fine.
Am I correct in assuming this is a bug?
Yes, it's Issue 5073.
(http://d.puremagic.com/issues/show_bug.cgi?id=5073). I've tested your
test case using the listed patch + DMD 2.051 and it works. The issue used
to be a bad compile time error in earlier compiler versions but in DMD
2.051 it turned into a runtime error. The underlying error in DMD has to
do with an alias of a delegate having a bad hidden pointer. The reason
commenting out 'auto y = x;' works is that the incorrect hidden pointer is
never called, thus never causing a segfault (IIRC). Issue 5073's patch
works by passing delegates by value instead of by alias. Looking over
Issue 5064, Don is probably right in it being the root cause in DMD, but
if you just want map to work correctly, you might want to try the patch
from 5073.
Re: review for unittests
On Saturday 29 January 2011 23:08:49 Jonathan M Davis wrote: On Saturday 29 January 2011 22:10:29 Andrei Alexandrescu wrote: On 01/29/2011 09:48 PM, Jonathan M Davis wrote: You mean 80 lines of code in the examples or in the actual code? I'm fine with 80 columns for examples, but I'll go insane if we start requiring 80 columns for normal code. That starts getting restrictive and ugly _really_ fast. Yes, once you go beyond 80 columns. You're quickly forced to put the next part of a statement on the next line just because you're hitting the 80 character limit instead of properly lining things up, and it makes them much harder to read. When Gutenberg built the first press, the resolution and the coarseness of the paper forced him to make the sheets pretty large. Since then the resolution of printing has increased amazingly, but people quickly figured out that reading is seriously impaired if the layout has more than about ten words per row of text. So in the hundreds of years that people have had available for improving printing media, the ten words pattern has stayed put. It's a human constant. Such a measure definitely to code, too. 80 columns should be enough for writing and reading meaningful code. Lines that go significantly beyond that limit have an intrinsic readability problem. I'm afraid that we're going to disagree on this one completely. Restricting code to 80 columns makes formatting a mess. You start doing things like breaking the next line based on how close it is to 80 columns rather than where it would make sense to break it based on the statement itself. Often, you're forced to put the remainder of the line on the next line simply indented somewhat more than the previous line rather than indenting it far enough to line up paretheses and function arguments. I much prefer lines that look like auto a = func(replace(str, hello, world), 13 + max(b, c)); to auto a = func(replace(str, hello,world), 13 + max(b, c)); or auto a = func(replace(str, hello,world), 13 + max(b, c)); Hmmm. The HTML seems to have been lost when I sent it (I don't normally try and put HTML in e-mails, so I guess I screwed it up), so the code isn't formatted properly... The idea, at least, is that the first one lines up the arguments for each function call, the second one just indents the second line, and the third one lines up the beginning of the second line with what's on the right-hand side of the assignment. It'll probably look correct if you copy and paste it into a code editor. - Jonathan M Davis
Re: review for unittests
On 01/30/2011 01:08 AM, Jonathan M Davis wrote: I'm afraid that we're going to disagree on this one completely. Restricting code to 80 columns makes formatting a mess. Apparently it's not a problem for all of my employers. All had such a standard. Facebook uses highlight-80+ with emacs and a commit hook to simply prevent lines longer than 80 characters from making it into the repository. So whereas I understand that you may not like the rule, I refute the implied objectivity of that argument. Code that fits in 80 columns is not a mess at least for some people. You start doing things like breaking the next line based on how close it is to 80 columns rather than where it would make sense to break it based on the statement itself. A statement that is so long is either over-indented or too long. In either case it should be breakable into bite-sized chunks. You need to break it to allow readers to read it easily, not to conform to an arbitrary rule. Often, you're forced to put the remainder of the line on the next line simply indented somewhat more than the previous line rather than indenting it far enough to line up paretheses and function arguments. I much prefer lines that look like auto a = func(replace(str, hello, world), 13 + max(b, c)); to auto a = func(replace(str, hello,world), 13 + max(b, c)); or auto a = func(replace(str, hello,world), 13 + max(b, c)); Formatting becomes a _big_ problem when you force 80 character lines - _especially_ if you use descriptive names for functions and variables. You'd be hard pressed to explain how quality code can arguably be written within 80 characters. And if you allow for greater than 80 character lines, then lines that would 90 or 100 characters and look just fine can be left on one line without having to worry about formatting problems at all. I worry that I don't see the code, or that it comes off stilted at the beginning of the next line. The problem becomes particularly bad if you have code with multiple levels of scope. All of a sudden, your inner loop has to have all of its code take multiple lines just because it's indented far enough to be close to 80 characters. Then the function is poorly written and needs to be refactored. The problems are never with the 80 characters. I appreciate that you have a different perspective because you have been used to writing e.g. 100-columns code, and you believe you'd be incredibly constrained otherwise. Believe me: you will write better code in 80 lines. The _only_ reason I see to restrict the number of columns on a line like that is for printing code. If you make lines too long, they won't fit on paper. But they'll fit just fine on a computer screen at well beyond 80 columns. With gvim, a line with 80 columns takes up less than a third of my screen - and that's with stuff like line numbers being shown. Unless you're specifically restricting the size of your edit windown to 80 columns, I don't see why having more than 80 characters on a line would be a problem. When you read a website, you don't maximize the browser (besides many sites forcibly limit the width of their text). Newspapers have columns to maximize parsing speed for their readers. And sure, you don't want lines getting to be 120 characters long and the like. There is a limit to how much it makes sense to put in a single statement. Let's choose that limit to be 80 characters. However, I have routinely found that when I've been restricted to 80 column lines, code becomes far harder to format properly, statements which really should be on one line are forced to be on multiple lines because they're a bit passed 80 characters, and the code is harder to read. I refute that because again there is overwhelming evidence to the contrary. I find that code is formatted much better when you're not strict about the length of lines and the like. You try and limit how long lines get, and you break them up on multiple lines when they start getting too long, but if you're strict about it, lines quickly become ill-formatted and harder to read. I understand. I hope you also understand that your argument has only subjective basis, with you as the subject. You are literally only the second or third fellow coder to ever tell me such. Jonathan, I won't continue debating this. There is something to be said about picking one's fights, and that goes both ways. I will only say this. Phobos is a team effort. As such, there is a simple necessity to find ways to live and let live in relative harmony. This means conforming to conventions that are not the most comfortable to us (that includes me; my favorite bracing is the one in TDPL, but when I write Phobos code I use Walter's). Also, there is sometimes a need to conform to authority that we might sometimes not agree with; but as certain decisions are subjective, some de facto authority must make some decisions to simply keep the style somewhat
Re: Are these (known) bugs?
Le 29/01/11 03:51, Jonathan M Davis a écrit :
On Friday 28 January 2011 13:55:03 Jonathan M Davis wrote:
On Friday, January 28, 2011 10:57:58 biozic wrote:
Hi,
I am playing with the to-be-released std.datetime, and encountered these
errors (the last one concerns std.variant, actually), with dmd 2.052
(Mac OS X 10.6):
---
import std.array, std.datetime, std.variant;
unittest {
auto app = appender!(Interval!Date[]);
auto interval = Interval!Date(Date(2000, 1, 1), Date(2011, 2, 3));
app.put(interval);
// Error: datetime.d(20208): Invariant Failure: begin is not before
or equal to end.
}
There no known bugs in std.datetime. My guess would be that the issue lies
with appender and Interval!(Date).init and/or something set to void if
appender does that at all. But since Date.init would be equal to
Date.init, it seems extremely bizarre that Interval!(Date).init would have
its begin and end not be equal, which makes it less likely that
Interval!(Date).init would be the problem. So, I don't know. The code is
very thoroughly tested, but that doesn't mean that I didn't miss
something, and it's possible that there's a bug in appender. I'm not at
all familiar with how appender works. I'll have to take a look at it
tonight.
But std.datetime has a ton of unit tests and, as far as I know, is
currently passing all of them on Linux, Windows, and OS X (I don't know
about FreeBSD). The most likely problems would be on OS X or FreeBSD,
since I don't have a system with either OS X or FreeBSD, and there could
be problems in time zones other than America/Los_Angeles - particularly on
Windows where you can't easily test time zones other than the one that
you're in - since all of my development has been done in
America/Los_Angeles. But I'm not aware of any bugs. So, if you do find
problems, please report them.
Okay. This is pretty much _has_ to be either a bug in appender or in the
compiler. It happens non-derministically. The exact same program will sometimes
work just fine and sometimes the invariant will fail. It almost has to be the
case that the values being used were initialized with garbage data. It's the
kind of thing that I'd expect if = void had been used. I don't see = void in the
appender code, but it _is_ calling GC functions such as GC.extend and GC.qalloc.
I don't know enough about appender or how those functions work, but I suspect
that something isn't being properly initialized before it's used. Open a bug
report on the issue. Someone with knowledge of appender is going to have to take
a look at it.
- Jonathan M Davis
Thanks for your answer. Indeed, the bug might concern
garbage-initialized structs during appending. It is reducible to:
---
import std.array;
struct Foo {
int a, b;
Foo opAssign(Foo rhs) {
a = rhs.a;
b = rhs.b;
return this;
}
invariant () {
assert (a = b);
}
}
unittest {
auto app = appender!(Foo[]);
auto foo = Foo(1, 2);
app.put(foo);
}
---
It involves calling an invariant() on a struct where opAssign is
overloaded. You have filed a report concerning such a problem in issue
#5058.
__gshared static versus static __gshared
Is this a bug? __gshared static i; makes i be thread-local, while static __gshared i; makes it be shared.
