short thoughts on D (like my twitter)
http://arsdnet.net/web.d/short-thoughts.html I sometimes find little things I want to comment on, but it isn't enough to make it's own page. So I've decided to make one page where I'll dump them from time to time, like a twitter, but not twitter because twitter sucks. I started with something I just found pretty cool: using to!enum(string) does super easy whitelisting of input! And, IFTI lets you avoid repeating yourself if you want a default value.
Re: short thoughts on D (like my twitter)
On 10/06/2011 18:12, Adam D. Ruppe wrote: http://arsdnet.net/web.d/short-thoughts.html I sometimes find little things I want to comment on, but it isn't enough to make it's own page. So I've decided to make one page where I'll dump them from time to time, like a twitter, but not twitter because twitter sucks. I started with something I just found pretty cool: using to!enum(string) does super easy whitelisting of input! And, IFTI lets you avoid repeating yourself if you want a default value. Is there some way to subscribe to this? It seems like it could be quite interesting, if I can't subscribe via rss/atom/twitter I'll never see it though. -- Robert http://octarineparrot.com/
Re: short thoughts on D (like my twitter)
Robert Clipsham wrote: Is there some way to subscribe to this? I actually have a twitter account, so I'll use it for this: http://twitter.com/#!/destructionator Actually posting the comments in twitter wouldn't work, but I'll post the link and a very brief summary on that account when I update this file or any other D related post.
Re: short thoughts on D (like my twitter)
Adam D. Ruppe destructiona...@gmail.com wrote in message news:istja4$1rua$1...@digitalmars.com... http://arsdnet.net/web.d/short-thoughts.html So I've decided to make one page where I'll dump them from time to time, like a twitter, but not twitter because twitter sucks. Heh, this quote wins teh intarnets. :) I've done the exact same thing with blogging. I *don't* have a blog, blogs are stupid bullshit. But I do have something that just happens to arguably be a lot like a blog and uses a blogging engine ;) I started with something I just found pretty cool: using to!enum(string) does super easy whitelisting of input! And, IFTI lets you avoid repeating yourself if you want a default value. It'd be better if there were just some sort of variant of to that indicated failure some other way (and to could be built out of it.) That way you wouldn't have to have the overhead of instantiating an exception (and any other throw/catch overhead there may or may not be) every time you have to use the default.
Re: short thoughts on D (like my twitter)
On 2011-06-10 12:21, Nick Sabalausky wrote: Adam D. Ruppe destructiona...@gmail.com wrote in message news:istja4$1rua$1...@digitalmars.com... http://arsdnet.net/web.d/short-thoughts.html So I've decided to make one page where I'll dump them from time to time, like a twitter, but not twitter because twitter sucks. Heh, this quote wins teh intarnets. :) I've done the exact same thing with blogging. I *don't* have a blog, blogs are stupid bullshit. But I do have something that just happens to arguably be a lot like a blog and uses a blogging engine ;) I started with something I just found pretty cool: using to!enum(string) does super easy whitelisting of input! And, IFTI lets you avoid repeating yourself if you want a default value. It'd be better if there were just some sort of variant of to that indicated failure some other way (and to could be built out of it.) That way you wouldn't have to have the overhead of instantiating an exception (and any other throw/catch overhead there may or may not be) every time you have to use the default. It came up in a discussion of isNumeric the other day (actually I think that it was on a bug report regarding isNumeric) that it would be benificial to add functions to std.conv which indicated whether to or parse would succeed or not, so that code where failure was likely could check first rather than having the overhead of the ConvException (which is frustratingly significant at this point). Unfortunately, there's a high risk that you would have to duplicate what to and parse are doing to do that (especially if you want all of those functions to be efficient), so I don't know what we're going to do about it. It _is_ something that should be looked into however. - Jonathan M Davis
Re: short thoughts on D (like my twitter)
Nick Sabalausky wrote: But I do have something that just happens to arguably be a lot like a blog and uses a blogging engine ;) Gah, only weens use blogging engines! I tend to just write my stuff as plain html files (like you can see here). Sometimes I'll factor out common things, but I usually don't venture far from plain text. On the feed issue, that's something that doesn't bug me either - I just keep a list of sites I like in my brain and check them whenever I have nothing better to do. This perhaps only works for me because I read so few sites! It'd be better if there were just some sort of variant of to that indicated failure some other way (and to could be built out of it.) Indeed, but nothing in phobos currently can quite do that... Some quick commentary on IFTI: I actually discovered this by accident. Of course, I use IFTI all over the place, like most D programmers probably do. But, since the T argument was a default one here, I often didn't specify it: int a = cgi.request!int(a); (Why use this instead of to!int(cgi.get[a])? The request implementation checks both get and post.) Then, I started adding it, but still specified: int a = cgi.request!int(a, 100); One time, I just didn't write the template argument and it still worked! While it's a really mundane feature of D, I still felt a bit of hey cool when it worked. The to!enum was another thing I didn't expect. I thought it would do the same as casting an int, but it works from name, which is actually very cool. More user friendly, and that white listing aspect is also pretty useful. mysql.query(select * from users where ~ to!string(cgi.request(field, Field.name)) ~ = ?, value); Building a sql string like that is fairly ugly, and normally, it'd be /completely/ insane. You're just begging for trivially easy sql injections. But, thanks to the enum acting as a whitelist, you actually can do that in D. (Note that while I'm putting this in the web.d directory and talking about cgi, lots of this stuff works on the command line too. Imagine an enum for command line flags - converting is easy, you can to!string one of the enums safely, you can list the arguments using reflection, and final switch() can be used to ensure you cover them all! D's enums have a lot of hidden treasures.)
Re: short thoughts on D (like my twitter)
Another thing that I'm not even ready to write html about,
but it works in great part thanks to alias.
===
import arsd.web;
class TestObject : ApiObject {
this(Site site, string identifier) {
id = identifier;
}
string id;
string sayHello() {
return hello from ~ id;
}
}
class Site : ApiProvider {
alias .TestObject TestObject;
}
mixin FancyMain!(Site);
===
http://arsdnet.net/cgi-bin/objdemo/TestObject/adam/say-hello
That url calls:
auto obj = new TestObject(site, adam);
auto result = obj.sayHello();
// output the return value to the user in a suitable format...
cgi.write(wrapIn(document, formatAs(html, result)));
behind the scenes. That formatAs() function can do some magical
things too. I'll write about it when I do my second html templating
article. override Element makeHtmlElement() can do some magical
things...
Wow, sidetracking!
class ApiProvider is the centerpiece of web.d. It uses D's
reflection capabilities to make a collection of standard D
methods, structs, and enums available to the outside world.
Your functions are accessible through a web browser interface
(plain html documents and forms) a javascript interface, and
whatever other external programs you want; even a shell script
can access unauthenticated functions in about 20 lines if you
have curl.
Anyway, until today, the access was for the most part, only procedural style.
http://arsdnet.net/cgi-bin/apidemo/get-a-box?color=red
Translates directly to getABox(Color.red); That's what you'd do
for all the site's functions.
Now, you can have classes too, as seen above. Previously, I'd
write things like
void powerOnVm(int vmId) { auto vm = VM.get(vmId); vm.powerOn(); }
Now, I should be able to just expose that VM object directly to
the user, without having to manually write that wrapper code!
I'll save the why details for when I do the full writeup (which
will be after I try actually using this for something - so I can
be sure it's actually useful the way it is now).
But the how has one thing I find very cool: the alias.
When using web.d, the magic reflection is only called on a single
class, and all a classes members must exist in one file...
...unless you add more with alias!
D's alias lets you introduce any kind of name into your class,
from anywhere. When the derivedMembers loop is run to generate
the reflection info, it sees those alias members too.
===
int foo() { return 10; }
class CoolApi : ApiProvider {
alias .foo foo;
}
mixin FancyMain!(CoolApi);
===
http://arsdnet.net/cgi-bin/objdemo/foo
Prints 10 - the free function becomes a part of the class, sort
of. Of course, being a free function, it can't actually access
the classes instance variables, and passing parameters to it
through the web interface is probably no good (suppose it needs
a database handle... the website user certainly can't provide
that!).
So, aliasing free functions isn't of much use.
Aliasing structs, enums, and classes though? Very nice. Write
your structs in another file and expose them to the public site
with a single alias line. Share enums from another module with
the world just by aliasing it in.
For the object demo, I did a class this way. The TestObject
could be moved to another module, and include functions the
whole thing can use. Yay! (This is why the first argument to the
constructor is your ApiProvider instance btw, so it can access
those instance variables, putting it ahead of free functions.)
The ApiProvider module might be nothing more* than a list of
imports and aliases, exposing certain portions of your
application to the public. Currently though, it ensures the
exposed classes all derive from ApiObject, but there's actually
no technical reason for this; I just thought it looked cleaner.
It might change as I actually use it.
structs and enums have no such restriction - you can alias them
in to your heart's content. But, their methods aren't accessible
from the outside like classes.
(On the other hand, their data members are. Class data members
are never exposed here; part of that is the procedural roots,
and part of it is that I assume instance variables are more likely
database handles and such than things the end user ought to have
access to.
Similarly, http://arsdnet.net/cgi-bin/objdemo/TestObject/adam/
gives no such method instead of dumping the variables. I'm
considering tying that into a particular method which can return
a struct or something.)
* Well, ApiProvider is also responsible for custom data formatting
for output to the browser, so it'd probably still do that. But
it could be limited to pure view like activities, without any
site logic function implementations.
Speaking of alias, another cool thing: alias one class method
to another name. The reflection picks it up, so it's now accessible
to the browser user both ways too! This surprised me actually -
I figured alias wouldn't show up in the reflection, but
[OT] D's community is awesome!
Seriously. You have a problem with something D-related? D-people are helpful, friendly and articulate. By contrast, I once again tried to get TortoiseHg/hg-git working with github. TortoiseHg's homepage has a big prominent download latest installer for your OS button (but worded better than that ;) ). It includes hg-git, mercurial, dulwich, all the requirements built right in with a nice installer. Great, right? Except a simple clone from github, modify, commit, push didn't work (just like it never did before). This time it was a little bit different, though. Something about not being head, and something else about bookmarks. Blah, blah, etc. That's all fine, of course. I can understand bugs getting in now and then, and even taking a little while to get sorted out, especially on a big major OSS project. So I filed a bug report. Now here's where the D world really shines: If this had been within the D sphere of influence, the response would most likely have been helpful, meaningful, friendly, you know, *good*. But with this, the response I got was three lower-cased, non-punctuated words: update your extensions ...WTF? Yea, way to be helpful. Thanks for nothing. At least it wasn't RTFM - whoever coinded that one seriously needs to be shot. But from my (admittedly still limited) experience, that sort of thing seems to be typical of places like BitBucket and Launchpad (I've had worse on Launchpad before, regarding Ubuntu: Ubuntu has a long-standing tradition of screwing up the screen resolution if you boot with your monitor off. But instead of doing anything sensible about it, like, say, marking it as Triaged at Low Priority and accepting that the problem even exists, it works like this: You post on the existing open report for it, and they scold you for using custom drivers. You point out that you get the same problem *without* using the custom drivers, and they insist you need to open a new report because your configuration is different than the OP. Ok, but there's about ten other reports (from other people who also had a different configuration) that did *exactly that*, which were promptly closed for being duplicates. WTF?!?) Anyway, I don't actually care about this issue anymore, and I'm not posting here looking for help on it. I dislike Git/TortoiseGit, but at least I can get by with them, whereas I've pretty much concluded at this point that hg-git just isn't worth bothering with. But the point is, I really appreciate how awesome the D community is compared to so many others.
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Thu, Jun 9, 2011 at 12:57 PM, Daniel Gibson metalcae...@gmail.comwrote: Am 09.06.2011 21:02, schrieb Walter Bright: On 6/9/2011 11:03 AM, Robert Clipsham wrote: So there is going to be a next one? Yes, maybe in 6 months or so. I'm very happy with how this one turned out. But next time we need to devise a tie-breaking rule. Any suggestions? A runoff? BTW, there's nothing in the rules preventing an author from tooting his own horn and doing a bit of marketing of their article(s) for votes! If I win I'll implement $great_feature_everyone_wants ;-) (If I win I port a D compiler to ARM/iOS would really make sense, when the price is an iPad - it's kind of ironic anyway that the price is a kind of computer that isn't supported by D) I would vote for you :D
Available D2 implementation on Windows besides DMD?
Hi, I'm looking to try out D2 after reading Andrei's D Programming book. What implementations are available besides DMD for the windows platform? I've looked at both GDC and LLVM-LDC but was unable to get either of them to work at least for version 2 of the language. The precompiled binaries on the gdc page seems to be for gdc version 1 of the language. LDC doesn't have any precompiled binaries at all for windows and my attempts to build it has so far failed. Any recommendations and advice on this is appreciated. I'm mainly interested in trying all these alternate implementations to see how well they can optimize code.
Re: Available D2 implementation on Windows besides DMD?
Am 10.06.2011 10:46, schrieb Victor T.: Hi, I'm looking to try out D2 after reading Andrei's D Programming book. What implementations are available besides DMD for the windows platform? I've looked at both GDC and LLVM-LDC but was unable to get either of them to work at least for version 2 of the language. The precompiled binaries on the gdc page seems to be for gdc version 1 of the language. LDC doesn't have any precompiled binaries at all for windows and my attempts to build it has so far failed. Any recommendations and advice on this is appreciated. I'm mainly interested in trying all these alternate implementations to see how well they can optimize code. Are you aware that the new official GDC page is https://bitbucket.org/goshawk/gdc/wiki/Home ? The download page contains snapshots for D2 on windows (and maybe D1 as well). Cheers, - Daniel
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 6/9/2011 5:10 PM, Robert Clipsham wrote: On 10/06/2011 00:40, Steven Schveighoffer wrote: On Thu, 09 Jun 2011 19:35:41 -0400, Walter Bright newshou...@digitalmars.com wrote: On 6/9/2011 12:57 PM, Daniel Gibson wrote: (If I win I port a D compiler to ARM/iOS would really make sense, when the price is an iPad - it's kind of ironic anyway that the price is a kind of computer that isn't supported by D) I thought a t-shirt as a prize would be awfully lame! I wrote this article on D, and all I got was this lousy!T shirt -Steve I would happily accept this as my runners up prize. If someone wants to edit up an image for a lousy!T shirt, I can see about getting it produced.
Re: Available D2 implementation on Windows besides DMD?
Am 10.06.2011 11:22, schrieb Victor T.:
Daniel Gibson metalcae...@gmail.com wrote in
news:issm47$10ia$4...@digitalmars.com:
Are you aware that the new official GDC page is
https://bitbucket.org/goshawk/gdc/wiki/Home ?
The download page contains snapshots for D2 on windows (and maybe D1
as well).
Cheers,
- Daniel
Yes that was the page I was talking about. Specifically, the precompiled
binaries here:
https://bitbucket.org/goshawk/gdc/downloads
It appears to work with version 1 of the D language spec. For example,
when I compile the following under gdc I get an error that writeln is
undefined:
import std.stdio;
void main()
{
writeln(quicktest\n);
}
However, changing it to writefln compiles and runs fine. Additionally, I
also tried passing in -fversion=2 to gdc to which it complains it's
invalid.
So it would appear the precompiled binaries made available do not support
D2.
Strange. I haven't got a windows box, but in the archive there's also a
libphobos2 and include/ also contains a d2 dir, so I thought D2 was
supported.
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 10/06/2011 01:15, Daniel Gibson wrote: Am 10.06.2011 02:06, schrieb Robert Clipsham: On 10/06/2011 00:56, Daniel Gibson wrote: Am 10.06.2011 01:35, schrieb Walter Bright: On 6/9/2011 12:57 PM, Daniel Gibson wrote: (If I win I port a D compiler to ARM/iOS would really make sense, when the price is an iPad - it's kind of ironic anyway that the price is a kind of computer that isn't supported by D) I thought a t-shirt as a prize would be awfully lame! Hmm D t-shirts would actually be kind of cool (maybe not as first price in an article contest but in general). Ever thought about selling D merchandise (t-shirts, mugs, stuff like that)? Not hugely complete, but: http://digitalmars.com/gift/index.html Cool - where is the link to that page hidden? http://digitalmars.com/sitemap.html - in the bar at the top there's a treasure chest. The sitemap is linked from the DM homepage. Couldn't find it in the digitalmars main page, the site map or the D page. Also black t-shirts and/or shirts with the D logo ( http://d-programming-language.org/images/dlogo.png ) would be nice :) (Funny fact: the german cafepress page translates Digital Mars to Digital März and Mars Mousepad to März Mousepad - März is german for the month March) Cheers, - Daniel -- Robert http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
Am 10.06.2011 13:33, schrieb Robert Clipsham: On 10/06/2011 01:15, Daniel Gibson wrote: Am 10.06.2011 02:06, schrieb Robert Clipsham: On 10/06/2011 00:56, Daniel Gibson wrote: Am 10.06.2011 01:35, schrieb Walter Bright: On 6/9/2011 12:57 PM, Daniel Gibson wrote: (If I win I port a D compiler to ARM/iOS would really make sense, when the price is an iPad - it's kind of ironic anyway that the price is a kind of computer that isn't supported by D) I thought a t-shirt as a prize would be awfully lame! Hmm D t-shirts would actually be kind of cool (maybe not as first price in an article contest but in general). Ever thought about selling D merchandise (t-shirts, mugs, stuff like that)? Not hugely complete, but: http://digitalmars.com/gift/index.html Cool - where is the link to that page hidden? http://digitalmars.com/sitemap.html - in the bar at the top there's a treasure chest. The sitemap is linked from the DM homepage. hmm the only thing that's missing is a treasure map leading to that chest ;)
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 10/06/2011 09:56, Walter Bright wrote: On 6/9/2011 5:10 PM, Robert Clipsham wrote: On 10/06/2011 00:40, Steven Schveighoffer wrote: On Thu, 09 Jun 2011 19:35:41 -0400, Walter Bright newshou...@digitalmars.com wrote: On 6/9/2011 12:57 PM, Daniel Gibson wrote: (If I win I port a D compiler to ARM/iOS would really make sense, when the price is an iPad - it's kind of ironic anyway that the price is a kind of computer that isn't supported by D) I thought a t-shirt as a prize would be awfully lame! I wrote this article on D, and all I got was this lousy!T shirt -Steve I would happily accept this as my runners up prize. If someone wants to edit up an image for a lousy!T shirt, I can see about getting it produced. You seem to be using cafe press for your other merchandise, there's a tool on there for custom t-shirts. http://www.cafepress.com/cp/customize/makeadesign2.aspx?clear=trueno=321color=6#designer It's probably easier to do it through there. If not, I could probably make an image. Also, hate to be a grammar nazi, but that should probably be I wrote this article /about/ D, and all I got was this lousy!T shirt. -- Robert http://octarineparrot.com/
Re: [OT] D's community is awesome!
On 10/06/2011 07:27, Nick Sabalausky wrote: Seriously. You have a problem with something D-related? D-people are helpful, friendly and articulate. For the most part, there'll always be people in the community who aren't. Just like every community gets a troll or two. By contrast, I once again tried to get TortoiseHg/hg-git working with github. TortoiseHg's homepage has a big prominent download latest installer for your OS button (but worded better than that ;) ). It includes hg-git, mercurial, dulwich, all the requirements built right in with a nice installer. Great, right? Except a simple clone from github, modify, commit, push didn't work (just like it never did before). This time it was a little bit different, though. Something about not being head, and something else about bookmarks. Blah, blah, etc. That's all fine, of course. I can understand bugs getting in now and then, and even taking a little while to get sorted out, especially on a big major OSS project. So I filed a bug report. Now here's where the D world really shines: If this had been within the D sphere of influence, the response would most likely have been helpful, meaningful, friendly, you know, *good*. But with this, the response I got was three lower-cased, non-punctuated words: update your extensions ...WTF? Yea, way to be helpful. Thanks for nothing. At least it wasn't RTFM - whoever coinded that one seriously needs to be shot. I find the people that tend to give these responses are people that are used to dealing with bug reports from users rather than developers - after a while you begin to drop the pleasantries because you're so used to giving a standard response which sorts it most of the time. Of course, this rather defeats the point of a bug tracker in my opinion. But from my (admittedly still limited) experience, that sort of thing seems to be typical of places like BitBucket and Launchpad (I've had worse on Launchpad before, regarding Ubuntu: Ubuntu has a long-standing tradition of screwing up the screen resolution if you boot with your monitor off. But instead of doing anything sensible about it, like, say, marking it as Triaged at Low Priority and accepting that the problem even exists, it works like this: You post on the existing open report for it, and they scold you for using custom drivers. You point out that you get the same problem *without* using the custom drivers, and they insist you need to open a new report because your configuration is different than the OP. Ok, but there's about ten other reports (from other people who also had a different configuration) that did *exactly that*, which were promptly closed for being duplicates. WTF?!?) It's unfortunate you've encountered such responses - I've not had a bad experience with any bitbucket project, launchpad was slightly different, but it was nothing terrible. With the github decentralized model I think it makes it even less likely, there's a far stronger community thanks to the way it encourages everyone to be able to work on a project at once, even if you aren't part of a core team. Sure, it's possible on launchpad/bitbucket, it doesn't seem to be as actively encouraged though. Anyway, I don't actually care about this issue anymore, and I'm not posting here looking for help on it. I dislike Git/TortoiseGit, but at least I can get by with them, whereas I've pretty much concluded at this point that hg-git just isn't worth bothering with. You're probably better off for it - I used to be strongly in the mercurial camp, but having used git for a while I find I vastly prefer it, despite still not knowing how to do quite a bit with it. But the point is, I really appreciate how awesome the D community is compared to so many others. /* I can't speak for everyone */ nick ~= (1/communities[D].length) * thanks; PS Sorry if this doesn't read well, I replied from bottom to top :S -- Robert http://octarineparrot.com/
Re: Available D2 implementation on Windows besides DMD?
On 10/06/2011 09:46, Victor T. wrote: Hi, I'm looking to try out D2 after reading Andrei's D Programming book. What implementations are available besides DMD for the windows platform? I've looked at both GDC and LLVM-LDC but was unable to get either of them to work at least for version 2 of the language. The precompiled binaries on the gdc page seems to be for gdc version 1 of the language. LDC doesn't have any precompiled binaries at all for windows and my attempts to build it has so far failed. Any recommendations and advice on this is appreciated. I'm mainly interested in trying all these alternate implementations to see how well they can optimize code. Your best option for D on Windows is dmd right now. It is implicitly more up to date than GDC/LDC (they both depend on the dmd front end, so there will inevitably be some amount of lag). GDC has D2 support and Windows support, I don't believe it offers pre-compiled binaries for D2 on Windows yet though. It should do in the near future, as gdc is actively developed, and people have been taking an interest in Windows support recently. LDC has alpha, maybe beta support for D2, and is behind dmd releases. It uses the LLVM backend, which doesn't support exceptions on Windows currently, so it's not much use. Note that the next release of LLVM will have support for exceptions on 64-bit Windows, no work has been done for 32 bit though, my guess is that will follow. As for how well they optimize code, dmd has a state of the art optimizer from the 90s, or there abouts - the code it generates is pretty speedy, it has some obvious short comings though (I believe floating point and inlining are lacking, as well as some more modern optimizations). GDC optimizes code almost as well as GCC, there are a few notable cases where it doesn't though - it's a matter of time before these are fixed though, by which time the code generated will be roughly the same speed as the equivalent C/C++. LDC optimizes code roughly as well as clang, and has some D specific optimizations too (something which GDC is lacking, and DMD too). As far as I'm aware these are nothing major though. -- Robert http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 09/06/2011 02:57, Brad Roberts wrote: On Wed, 8 Jun 2011, Moritz Warning wrote: Congratulations to both winners! Pfft, if I have had time to vote, I might have robbed one of his prize (sorry Brad). :) I hadn't brought it up yet, but the fact that there were only 25 votes is, really, fairly sad. I too didn't vote. I know this community is _far_ larger than 25 people. Heck, even the number of posters to this forum is larger. Why? Later, Brad In my case, I haven't read the articles, didn't have the time yet. It's not just the articles though, other more in-depth stuff I haven't yet had the time to go look into it (for example, TDPL itself). So that's why I didn't vote... -- Bruno Medeiros - Software Engineer
Re: [OT] D's community is awesome!
Am 10.06.2011, 13:48 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com: You're probably better off for it - I used to be strongly in the mercurial camp, but having used git for a while I find I vastly prefer it, despite still not knowing how to do quite a bit with it. Yep, Mercurial's biggest drawback imo is that bookmarks (which let you do something analogous to git's branches) aren't standard and thus aren't pushed/pulled by default. And of course github is way better than bitbucket, but that's not Mercurial's fault I admit.
Re: Available D2 implementation on Windows besides DMD?
Am 10.06.2011, 14:01 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com: LDC has alpha, maybe beta support for D2, and is behind dmd releases. It uses the LLVM backend, which doesn't support exceptions on Windows currently, so it's not much use. Note that the next release of LLVM will have support for exceptions on 64-bit Windows, no work has been done for 32 bit though, my guess is that will follow. Woot! That's great news, Win64 support is all I need :)
Re: Article discussing Go, could well be D
On 06/09/2011 03:27 AM, Nick Sabalausky wrote: Once again, I wasn't Pike-bashing. You're misinterpreting my words and assuming I did. Billions of people, obviously myself included, have never done *anything* of real significant note whether recently or 800 years ago. And everyone knows that. So how the heck can saying some guy who did something significant 40 years ago and hasn't done a damn thing of note since even *possibly* be taken as an insult? Maybe because he has done things of note since? Who is it for you to judge? And then comparing him against Andrei, to boot. I don't want to get into a debate on his career, or turn this into an Andre vs Pike flamefest, so I won't drag up what people have worked on. My point is you didn't have to go there. Yes, what you did was inflammatory and ad hominem.
Re: [OT] D's community is awesome!
On Fri, 10 Jun 2011 12:48:30 +0100, Robert Clipsham wrote: /* I can't speak for everyone */ nick ~= (1/communities[D].length) * thanks; I hope 'communities[D].length' isn't an integer! :) Graham
Re: Article discussing Go, could well be D
On 06/09/2011 03:36 AM, Nick Sabalausky wrote: So he flat out *states* that he passed over D and gave Issue 9 a try *because* of what was done decades ago by one of the people involved. OK, I missed that, because I searched for Pike in the article, and he mentioned Thompson. Your post didn't mention anybody explicitly by name, except for that Issue 9 guy. Considering that Pike has been the face of Go, it was a reasonable assumption. You still didn't need to pass judgment on what is notable or not in their later careers. It's enough to say that dismissing D as being irrelevant without justification is the problem. Also, there's nothing wrong with taking a look at a C-like language because the inventors were heavily involved with the original C and Unix environments. Much like people are encouraged to look at D because of Walter's past work with a C++ compiler and Andrei's C++ experience. As a way to pique interest, it's valid. However, that should not be a determination of a language's actual merit.
[upforgrabs] tools/update
We need a script to update all of dmd's paraphernalia. By this I'm putting the task up for grabs and am describing it. The script would require git to be installed, and would orchestrate git commands to freshen the installation. Either a tag can be given, or the script would automatically detect the latest semistable release, or even the script can be told to get the latest and greatest. The exact tagging convention is to be defined later. The trick with such tools is they must just work. That means wherever and however you installed dmd, the script should be able to detect everything it needs for a successful update. This means: dmd and rdmd binary locations, druntime and phobos library locations, and druntime and phobos import locations. The way I'm thinking this all can be done is by running dmd -v against a small do-nothing program that imports one std module, for example std.stdio. The run will print (among other things): binarydmd version v2.054 config/Users/john/dmd.conf parse test importall test importobject(/Users/john/code/dmd/druntime/import/object.di) importstd.stdio (/Users/john/code/dmd/phobos/std/stdio.d) ... Simple parsing reveals the location of the configuration file and the locations of druntime and std imports. Further simple parsing of the conf file reveals the location of libraries. With this information in hand, the script goes and fetches the appropriate code in the appropriate places. Also, the tool needs to do all of its work transactionally, i.e. first download everything next to the target with an added suffix (e.g. .tmp). Only after a full successful download, the tool would rename everything .tmp to its final name (an operation that can't fail under most circumstances). If anyone is willing to take up working on this, it would be great. D itself is a great candidate as the language to write the tool in, and has the advantage of being more portable than shell scripts. We'll add the tool to the tools/ repository and offer it with the standard distribution. Thanks, Andrei
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Fri, 10 Jun 2011 07:36:10 -0400, Robert Clipsham rob...@octarineparrot.com wrote: Also, hate to be a grammar nazi, but that should probably be I wrote this article /about/ D, and all I got was this lousy!T shirt. Considering this was a *writing* contest, it should probably be grammatically correct :) -Steve
Re: Available D2 implementation on Windows besides DMD?
Am 10.06.2011, 14:01 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com: Note that the next release of LLVM will have support for exceptions on 64-bit Windows, no work has been done for 32 bit though, my guess is that will follow. What is your source? I could only find this changeset which adds SEH parsing and AST support to Clang: https://llvm.org/viewvc/llvm-project?view=revsortby=daterevision=130366
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Fri, 10 Jun 2011 10:31:53 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Fri, 10 Jun 2011 07:36:10 -0400, Robert Clipsham rob...@octarineparrot.com wrote: Also, hate to be a grammar nazi, but that should probably be I wrote this article /about/ D, and all I got was this lousy!T shirt. Considering this was a *writing* contest, it should probably be grammatically correct :) That reminds me, at my former company, we had a release of a BSD-based appliance. The marketing department thought it would be clever to give us all mugs that said \dev\mug. I had to change it to forward slashes with a sharpie, I just couldn't look at it without that :) -Steve
Re: [upforgrabs] tools/update
I thought this is what DVM already does? Or are you talking about fetching unstable branches and compiling/installing them?
Re: Available D2 implementation on Windows besides DMD?
On 6/10/11, Victor T. gmane.greatw...@mamber.net wrote:
void main()
{
writeln(quicktest\n);
}
However, changing it to writefln compiles and runs fine. Additionally, I
also tried passing in -fversion=2 to gdc to which it complains it's
invalid.
gdc -v2 main.d
Flag proposal
https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei
Re: Article discussing Go, could well be D
On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: That's it. We need a package management expert on board to either revive dsss or another similar project, or define a new package manager altogether. No yeah I have some code somewhere feel free to copy from it; we need professional execution. Then we need to make that tool part of the standard distribution such that library discovery, installation, and management is as easy as running a command. I'm putting this up for grabs. It's an important project of high impact. Wondering what you could do to help D? Take this to completion. Andrei Andrei, I have to respectfully disagree with you on that, sorry. D is supposed to be a system programming language, not some scripting language like Ruby. Besides, the idea of some kind of package management for a programming language is one of the worst ideas ever, specially when it's a system programming language. You have no idea how much pain and suffering it's going to cause the OS developers and package maintainers. I can see how the idea might be attractive to non-*nix users, but most other *nix OSs have some kind of package management system and searching for, installing, and managing software is as easy as running a command.
Re: Flag proposal
I like how your proposal is already a pull request. I'm not too fond of this workaround: bool state; getopt( args, state, state, ); auto line = getLine(cast(Flag!KeepTerminator)state); Will getopt know how to use Flags? What about std.conv.to? std.format/write will have to know how to print out a Flag too, or we have to cast: writeln(cast(bool)keepTerminator); If the plan is to replace all boolean arguments in Phobos with Flags, won't this break a lot of code? We'll have to switch to using this template, and then if we finally get named arguments sometime down the road we will have to convert everything back to bools again.
Re: Article discussing Go, could well be D
Caligo wrote: On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: That's it. We need a package management expert on board to either revive dsss or another similar project, or define a new package manager altogether. No yeah I have some code somewhere feel free to copy from it; we need professional execution. Then we need to make that tool part of the standard distribution such that library discovery, installation, and management is as easy as running a command. I'm putting this up for grabs. It's an important project of high impact. Wondering what you could do to help D? Take this to completion. Andrei Andrei, I have to respectfully disagree with you on that, sorry. D is supposed to be a system programming language, not some scripting language like Ruby. Besides, the idea of some kind of package management for a programming language is one of the worst ideas ever, specially when it's a system programming language. You have no idea how much pain and suffering it's going to cause the OS developers and package maintainers. I can see how the idea might be attractive to non-*nix users, but most other *nix OSs have some kind of package management system and searching for, installing, and managing software is as easy as running a command. For software libraries it is a different case imho, for the following reasons: - for most software development needs, not enough libraries get packaged by the major distro's - there's no way library authors are going to maintain packages of their libs for all the popular distro's with their incompatible systems - distro maintainers often package older versions, sometimes they are years behind - most, if not all native package management systems deal poorly with the need for having several versions of a library available. So there is still a need for tools like virtualenv. With dsss it's also trivial to setup multiple installations to manage version requirements - language specific package management can span across operating systems The net result is that languages which have package managers (python, ruby, haskell, perl and now also .net) have in fact far more and up to date libraries available than any distro will ever be able to manage.
Re: Article discussing Go, could well be D
Caligo: Besides, the idea of some kind of package management for a programming language is one of the worst ideas ever, specially when it's a system programming language. D seems acceptable as an application programming language too. And in Haskell I am appreciating Cabal with Hackage: http://www.haskell.org/cabal/ Bye, bearophile
Re: Available D2 implementation on Windows besides DMD?
On 10/06/2011 15:34, Trass3r wrote: Am 10.06.2011, 14:01 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com: Note that the next release of LLVM will have support for exceptions on 64-bit Windows, no work has been done for 32 bit though, my guess is that will follow. What is your source? I could only find this changeset which adds SEH parsing and AST support to Clang: https://llvm.org/viewvc/llvm-project?view=revsortby=daterevision=130366 There are a lot of other commits for it, and some mailing list entries, you can find a selection here: Commits: http://goo.gl/efoVp http://goo.gl/iXGlT http://goo.gl/qe9u1 Mailing list entries: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-June/040442.html -- Robert http://octarineparrot.com/
Historical moment: D2 is now D
I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Thanks, Andrei
Re: Article discussing Go, could well be D
On 2011-06-10 09:29, Caligo wrote: On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: That's it. We need a package management expert on board to either revive dsss or another similar project, or define a new package manager altogether. No yeah I have some code somewhere feel free to copy from it; we need professional execution. Then we need to make that tool part of the standard distribution such that library discovery, installation, and management is as easy as running a command. I'm putting this up for grabs. It's an important project of high impact. Wondering what you could do to help D? Take this to completion. Andrei Andrei, I have to respectfully disagree with you on that, sorry. D is supposed to be a system programming language, not some scripting language like Ruby. Besides, the idea of some kind of package management for a programming language is one of the worst ideas ever, specially when it's a system programming language. You have no idea how much pain and suffering it's going to cause the OS developers and package maintainers. I can see how the idea might be attractive to non-*nix users, but most other *nix OSs have some kind of package management system and searching for, installing, and managing software is as easy as running a command. Personally, I don't care much. However, there _are_ other *nix languages which do this sort of thing - e.g. Perl has CPAN. And even if the distro doesn't use it, it's likely to make their job in getting their packages set up properly. And if having a packaging system for D libraries helps boost the language, then I have no problem with it. But ultimately, how much value it adds will depend on what it does and how it works, and we won't know that until it's been design and implemented, which obviously hasn't been done yet. - Jonathan M Davis
Re: Article discussing Go, could well be D
On 6/10/11 11:29 AM, Caligo wrote: On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: That's it. We need a package management expert on board to either revive dsss or another similar project, or define a new package manager altogether. No yeah I have some code somewhere feel free to copy from it; we need professional execution. Then we need to make that tool part of the standard distribution such that library discovery, installation, and management is as easy as running a command. I'm putting this up for grabs. It's an important project of high impact. Wondering what you could do to help D? Take this to completion. Andrei Andrei, I have to respectfully disagree with you on that, sorry. D is supposed to be a system programming language, not some scripting language like Ruby. Besides, the idea of some kind of package management for a programming language is one of the worst ideas ever, specially when it's a system programming language. You have no idea how much pain and suffering it's going to cause the OS developers and package maintainers. I can see how the idea might be attractive to non-*nix users, but most other *nix OSs have some kind of package management system and searching for, installing, and managing software is as easy as running a command. I don't find this counterargument very strong but am attracted to me because it entails no work on my part :o). FWIW other language distributions that position themselves as system languages do embed package management. I personally don't think the two notions exclude one another (without being an expert). At least, a variety of non-standard libraries should avail themselves of a simple just works package and versioning amenity. Andrei
Re: Historical moment: D2 is now D
On 2011-06-10 10:06, Andrei Alexandrescu wrote: I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Woohoo! - Jonathan M Davis
Re: Flag proposal
On 6/10/11 11:45 AM, Andrej Mitrovic wrote: I like how your proposal is already a pull request. I'm not too fond of this workaround: bool state; getopt( args, state,state, ); auto line = getLine(cast(Flag!KeepTerminator)state); Will getopt know how to use Flags? What about std.conv.to? Yes, getopt should support any enum using bool as its base. std.conv already supports all enums. std.format/write will have to know how to print out a Flag too, or we have to cast: writeln(cast(bool)keepTerminator); Without the cast, writeln prints yes or no, which may be desirable. If you want to print the bool, you can say writeln(keepTerminator == Flag!KeepTerminator.yes); or writeln(!!keepTerminator); etc. I find this array of options quite sensible. If the plan is to replace all boolean arguments in Phobos with Flags, won't this break a lot of code? Migration can be done piecemeal with deprecation and all. We'll have to switch to using this template, and then if we finally get named arguments sometime down the road we will have to convert everything back to bools again. If we convert back to bool the problem remains that people still can just pass true or whatever without specifying the name of the parameter. True, they could and should specify the name of the parameter, but by that argument they could and should insert a comment right now - and nobody does. Andrei
Re: [OT] D's community is awesome!
On 10/06/2011 15:14, Graham Fawcett wrote: On Fri, 10 Jun 2011 12:48:30 +0100, Robert Clipsham wrote: /* I can't speak for everyone */ nick ~= (1/communities[D].length) * thanks; I hope 'communities[D].length' isn't an integer! :) Graham What, my code has to be valid as well now?! What sort of community is this? :D -- Robert http://octarineparrot.com/
Re: Historical moment: D2 is now D
On 10/06/2011 18:06, Andrei Alexandrescu wrote: I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Thanks, Andrei I always find it incredibly annoying when I don't see the syntax of a language on its homepage. You shouldn't have to scroll down to see it. Also, the example that is there is terrible and represents the state of an old D1, it needs updating to use cool D2 features like CTFE and std.parallelism. I'd avoid templates and __traits() and other more advanced features, we don't want to put people off by putting too much on their plate! Also, a lot of the links on there link to digitalmars.com still. -- Robert http://octarineparrot.com/
Re: Flag proposal
*notice
Re: Flag proposal
On 6/10/11, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Without the cast, writeln prints yes or no, which may be desirable. If you want to print the bool, you can say writeln(keepTerminator == Flag!KeepTerminator.yes); or writeln(!!keepTerminator); Oh, maybe this was already incorporated into format but I didn't nocie, I just did a blunt copy/paste of the template code so it didn't work for me: D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(1624): Error: template std.format.formatValue(Writer,T,Char) if (is(const(T) == const(void[]))) formatValue(Writer,T,Char) if (is(const(T) == const(void[]))) matches more than one template declaration, D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(895):formatValue(Writer,T,Char) if (is(T == enum)) and D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(1104):formatValue(Writer,T,Char) if (is(T : bool))
Re: [upforgrabs] tools/update
Plus thanks to Nick dvm now works on Windoze.
Re: Flag proposal
On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. -- Robert http://octarineparrot.com/
Re: Historical moment: D2 is now D
On 2011-06-10 10:39, Robert Clipsham wrote: On 10/06/2011 18:06, Andrei Alexandrescu wrote: I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Thanks, Andrei I always find it incredibly annoying when I don't see the syntax of a language on its homepage. You shouldn't have to scroll down to see it. Also, the example that is there is terrible and represents the state of an old D1, it needs updating to use cool D2 features like CTFE and std.parallelism. I'd avoid templates and __traits() and other more advanced features, we don't want to put people off by putting too much on their plate! There was a request for a better example a while back, and AFAIK, no one came up with one. As soon as someone does, I'm sure that we can get it used instead. - Jonathan M Davis
Re: Flag proposal
On Jun 11, 11 01:41, Andrej Mitrovic wrote: On 6/10/11, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Without the cast, writeln prints yes or no, which may be desirable. If you want to print the bool, you can say writeln(keepTerminator == Flag!KeepTerminator.yes); or writeln(!!keepTerminator); Oh, maybe this was already incorporated into format but I didn't nocie, I just did a blunt copy/paste of the template code so it didn't work for me: D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(1624): Error: template std.format.formatValue(Writer,T,Char) if (is(const(T) == const(void[]))) formatValue(Writer,T,Char) if (is(const(T) == const(void[]))) matches more than one template declaration, D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(895):formatValue(Writer,T,Char) if (is(T == enum)) and D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\format.d(1104):formatValue(Writer,T,Char) if (is(T : bool)) Try to use the Phobos on git master. I have fixed this already (bug 5837) and the patch has been merged on June 3rd.
Re: Historical moment: D2 is now D
Very cool. Note: The Downloads Tools link redirects to the digitalmars.com website here: http://www.digitalmars.com/d/download.html instead of here: http://d-programming-language.org/dmd-linux.html This latter page already has the links to the download page, but this section has the compiler documentation which is important.
Re: Flag proposal
On Jun 11, 11 01:42, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. Well I agree it is ugly, but at least it's better than having the same enum 7 times in Phobos (std.stdio.KeepTerminator, std.string.CaseSensitive, std.algorithm.OpenRight, std.algorithm.SortOutput, std.datetime.AllowDayOverflow, std.datetime.PopFirst, std.datetime.AutoStart). If named parameter is supported, those Flag!foo parameters can be reverted back to bool without breaking the caller as the enum is based on bool.
Re: Article discussing Go, could well be D
On Fri, Jun 10, 2011 at 9:29 AM, Caligo iteronve...@gmail.com wrote: On Wed, Jun 8, 2011 at 6:06 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: That's it. We need a package management expert on board to either revive dsss or another similar project, or define a new package manager altogether. No yeah I have some code somewhere feel free to copy from it; we need professional execution. Then we need to make that tool part of the standard distribution such that library discovery, installation, and management is as easy as running a command. I'm putting this up for grabs. It's an important project of high impact. Wondering what you could do to help D? Take this to completion. Andrei Andrei, I have to respectfully disagree with you on that, sorry. D is supposed to be a system programming language, not some scripting language like Ruby. Besides, the idea of some kind of package management for a programming language is one of the worst ideas ever, specially when it's a system programming language. You have no idea how much pain and suffering it's going to cause the OS developers and package maintainers. I can see how the idea might be attractive to non-*nix users, but most other *nix OSs have some kind of package management system and searching for, installing, and managing software is as easy as running a command. It doesn't have to be hard if you build the package manager in such a way that it can be integrated into the OS package manager, whether that means letting the OS package manager modify the language package manager's database or just adding a switch that turns your package manager into a dumb build tool so dependency checks can be left to the OS package manager. That's my theory, anyway.
Re: Article discussing Go, could well be D
On Wed, Jun 8, 2011 at 4:06 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 6/8/11 4:38 PM, Brad Anderson wrote: On Wed, Jun 8, 2011 at 12:46 AM, Lars T. Kyllingstad public@kyllingen.nospamnet wrote: http://www.reddit.com/r/programming/comments/hudvd/ the_go_programming_language_or_why_all_clike/ The author presents a wish list for his perfect systems programming language, and claims that Go is the only one (somewhat) fulfilling it. With the exception of item 7, the list could well be an advertisement for D. -Lars I found the comments on the Hacker News post http://news.ycombinator.com/item?id=2631964 about this article more interesting. Regards, Brad Anderson Agreed. The top poster does repeat a point made by others: D does fail on point 7. Allow me to paste it: = 7. Module Library and Repository I want all the niceties I have grown used to in scripting languages built-in or part of the standard library. A public package repository with a decent portable package manager is even better. Typical packages include internet protocols, parsing of common syntaxes, GUI, crypto, common mathematical algorithms, data processing and so on. (Example: Perl 5 CPAN) = That's it. We need a package management expert on board to either revive dsss or another similar project, or define a new package manager altogether. No yeah I have some code somewhere feel free to copy from it; we need professional execution. Then we need to make that tool part of the standard distribution such that library discovery, installation, and management is as easy as running a command. I'm putting this up for grabs. It's an important project of high impact. Wondering what you could do to help D? Take this to completion. I'm not an expert, but I've been quietly working on a build tool that I'm hoping to make into a drop-in replacement for dsss with the incremental build advantages of xfbuild. I'll toss it on github when it can parse a dsss config and build from that. Right now, it's basically a very simple xfbuild. As for the packaging aspect of dsss, I'll have to take a closer look at how it was originally implemented.
Re: Article discussing Go, could well be D
I think we should go for immutable packages. It makes the package managed infinitely simpler: if the file is there, use it. If not, download it, then use it. Since it's immutable, you can always use your file. How do you push updates then? Easy - change the name. Put the version number in the module name.
Re: Flag proposal
On 6/10/11 12:42 PM, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. This is not half-baked. It's pretty much it. Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. Andrei
Re: [upforgrabs] tools/update
On 6/10/11 12:34 PM, Robert Clipsham wrote: This sounds like a rather limited tool, why limit it to dmd? The tool you describe is just a watered down version of a full package manager. Then define a full package manager and have the tool use it. Also, as already mentioned, dvm does this. From what I saw it doesn't do all that. Andrei
Re: Flag proposal
On 2011-06-10 10:57, KennyTM~ wrote: On Jun 11, 11 01:42, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. Well I agree it is ugly, but at least it's better than having the same enum 7 times in Phobos (std.stdio.KeepTerminator, std.string.CaseSensitive, std.algorithm.OpenRight, std.algorithm.SortOutput, std.datetime.AllowDayOverflow, std.datetime.PopFirst, std.datetime.AutoStart). If named parameter is supported, those Flag!foo parameters can be reverted back to bool without breaking the caller as the enum is based on bool. And there are places in Phobos which _should_ be using enums like this but aren't (e.g. std.file.dirEntries' followSymlinks bool), so the number is only going to go up as such things are fixed, even without adding new code to Phobos. And of course, we're going to be adding new code, so the amount of duplication for this type of enum is only going to go up. - Jonathan M Davis
Re: Article discussing Go, could well be D
On Fri, Jun 10, 2011 at 11:10 AM, Adam D. Ruppe destructiona...@gmail.comwrote: I think we should go for immutable packages. It makes the package managed infinitely simpler: if the file is there, use it. If not, download it, then use it. Since it's immutable, you can always use your file. How do you push updates then? Easy - change the name. Put the version number in the module name. I agree, and this is the approach of Java tools like Maven and Ant/Ivy. Package a release and label it with the version, then never ever modify it. This makes it hard to work with the trunk of a project (though an exceptional case could be made if there's enough justification), but with enough developmental releases, it seems to work pretty well.
Re: Flag proposal
On 10/06/2011 19:06, Andrei Alexandrescu wrote: On 6/10/11 12:42 PM, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. This is not half-baked. It's pretty much it. My choice of wording was poor, sorry. Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. void foo(bool param, bool otherParam, bool thisOneIsntRequired = false); Call it with or without named parameters, two are required, one is not. foo(otherParam: true, param: false); foo(true, false); foo(otherParam: true, param: false, thisOneIsntRequired: true); Would all be valid. Andrei -- Robert http://octarineparrot.com/
Re: Article discussing Go, could well be D
On Fri, 2011-06-10 at 11:29 -0700, Andrew Wiley wrote: [ . . . ] I agree, and this is the approach of Java tools like Maven and Ant/Ivy. Package a release and label it with the version, then never ever modify it. This makes it hard to work with the trunk of a project (though an exceptional case could be made if there's enough justification), but with enough developmental releases, it seems to work pretty well. Working with trunk is easy, there is the snapshots repository (at least at Codehaus). artefacts in this repository are NOT immutable and build frameworks have a responsibility to check and act accordingly. Gradle does, Maven sometimes does, Ant/Ivy tends to get it wrong without extra help. -- 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: Flag proposal
On 2011-06-10 14:52:53 -0400, Robert Clipsham rob...@octarineparrot.com said: On 10/06/2011 19:06, Andrei Alexandrescu wrote: Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I have to say I totally agree with Robert. I agree with the need for a way to name parameters, but instantiating a pseudo-boolean type from a template for each function parameter is worse than the initial problem. Templates are already a difficult concept to grasp for most people (because they're so abstract), we really don't need to replace every boolean parameter with a template type. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. void foo(bool param, bool otherParam, bool thisOneIsntRequired = false); Call it with or without named parameters, two are required, one is not. foo(otherParam: true, param: false); foo(true, false); foo(otherParam: true, param: false, thisOneIsntRequired: true); And just try to think of the signature for the function above if it was using Flag! void foo(Flag!param param, Flag!otherParam otherParam, Flag!thisOneIsntRequired thisOneIsntRequired = Flag!thisOneIsntRequired.no); Do we really want to expose that in the documentation? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Flag proposal
On 2011-06-10 09:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! I do have to admit that as much as I hate the idea of named parameters, this particular proposal certainly seems to be an argument in favor of adding them, which would tend to argue against making these changes. After thinking about it, I'd argue that it would be better to create a string mixin which created the enums for you instead of using the template as part of the arguments. e.g. mixin(YesNoEnum!KeepTerminator)); Then all of the rest of the code is the same. You'd still use KeepTerminator.yes and KeepTerminator.no, but we avoided having to create duplicate enums by hand every time that we want this kind of variable. So, you still reduce the boilerplate code, but the usage is much less ugly. - Jonathan M Davis
Re: Flag proposal
On Jun 11, 11 03:30, Jonathan M Davis wrote: On 2011-06-10 09:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! I do have to admit that as much as I hate the idea of named parameters, this particular proposal certainly seems to be an argument in favor of adding them, which would tend to argue against making these changes. After thinking about it, I'd argue that it would be better to create a string mixin which created the enums for you instead of using the template as part of the arguments. e.g. mixin(YesNoEnum!KeepTerminator)); Then all of the rest of the code is the same. You'd still use KeepTerminator.yes and KeepTerminator.no, but we avoided having to create duplicate enums by hand every time that we want this kind of variable. So, you still reduce the boilerplate code, but the usage is much less ugly. - Jonathan M Davis The problem is the 'YesNoEnum!KeepTerminator' will not be shown along with the DDoc of 'getLine'.
Re: Flag proposal
On Jun 11, 11 02:06, Andrei Alexandrescu wrote: On 6/10/11 12:42 PM, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. This is not half-baked. It's pretty much it. Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. Andrei Making the compulsory enum name as a feature means http://www.digitalmars.com/d/archives/digitalmars/D/8524.html will never be addressed, I suppose.
Re: Flag proposal
On 2011-06-10 12:33, KennyTM~ wrote: On Jun 11, 11 03:30, Jonathan M Davis wrote: On 2011-06-10 09:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! I do have to admit that as much as I hate the idea of named parameters, this particular proposal certainly seems to be an argument in favor of adding them, which would tend to argue against making these changes. After thinking about it, I'd argue that it would be better to create a string mixin which created the enums for you instead of using the template as part of the arguments. e.g. mixin(YesNoEnum!KeepTerminator)); Then all of the rest of the code is the same. You'd still use KeepTerminator.yes and KeepTerminator.no, but we avoided having to create duplicate enums by hand every time that we want this kind of variable. So, you still reduce the boilerplate code, but the usage is much less ugly. - Jonathan M Davis The problem is the 'YesNoEnum!KeepTerminator' will not be shown along with the DDoc of 'getLine'. Why would it be? You generally want documentation specific to the enum anyway, so that isn't exactly boilerplate. You'd just stick the documentation above the mixin. And if you don't want to do that but want it in the documentation for the function that uses it (particularly if there's only one - though that's often not the case), then just put the documentation in the function's documentation. Andrei's current solution does nothing for documentation, and arguably makes it worse, because there's no place to put documentation on the enum directly if you need to. - Jonathan M Davis
Re: Flag proposal
On Jun 11, 11 03:40, Jonathan M Davis wrote: On 2011-06-10 12:33, KennyTM~ wrote: On Jun 11, 11 03:30, Jonathan M Davis wrote: On 2011-06-10 09:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! I do have to admit that as much as I hate the idea of named parameters, this particular proposal certainly seems to be an argument in favor of adding them, which would tend to argue against making these changes. After thinking about it, I'd argue that it would be better to create a string mixin which created the enums for you instead of using the template as part of the arguments. e.g. mixin(YesNoEnum!KeepTerminator)); Then all of the rest of the code is the same. You'd still use KeepTerminator.yes and KeepTerminator.no, but we avoided having to create duplicate enums by hand every time that we want this kind of variable. So, you still reduce the boilerplate code, but the usage is much less ugly. - Jonathan M Davis The problem is the 'YesNoEnum!KeepTerminator' will not be shown along with the DDoc of 'getLine'. Why would it be? You generally want documentation specific to the enum anyway, so that isn't exactly boilerplate. You'd just stick the documentation above the mixin. And if you don't want to do that but want it in the documentation for the function that uses it (particularly if there's only one - though that's often not the case), then just put the documentation in the function's documentation. Andrei's current solution does nothing for documentation, and arguably makes it worse, because there's no place to put documentation on the enum directly if you need to. - Jonathan M Davis Please review the previous discussion of why Flag (was YesOrNo) was proposed. http://www.digitalmars.com/d/archives/digitalmars/D/YesOrNo_useful_idiom_helper_or_wanking_134392.html
Re: Flag proposal
Michel Fortin michel.for...@michelf.com wrote in message news:istqjn$2jld$1...@digitalmars.com... On 2011-06-10 14:52:53 -0400, Robert Clipsham rob...@octarineparrot.com said: On 10/06/2011 19:06, Andrei Alexandrescu wrote: Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I have to say I totally agree with Robert. I agree with the need for a way to name parameters, but instantiating a pseudo-boolean type from a template for each function parameter is worse than the initial problem. Templates are already a difficult concept to grasp for most people (because they're so abstract), we really don't need to replace every boolean parameter with a template type. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. void foo(bool param, bool otherParam, bool thisOneIsntRequired = false); Call it with or without named parameters, two are required, one is not. foo(otherParam: true, param: false); foo(true, false); foo(otherParam: true, param: false, thisOneIsntRequired: true); And just try to think of the signature for the function above if it was using Flag! void foo(Flag!param param, Flag!otherParam otherParam, Flag!thisOneIsntRequired thisOneIsntRequired = Flag!thisOneIsntRequired.no); Do we really want to expose that in the documentation? I completely agree with Robert and Michel on all the points they've raised. Flag is admittedly a great example of the power of D's templates. And it's admittedly a very clever hack to get around *some* of the limitations of not having named parameters...*But* it's *still* just that: a hack to get around some of the limitations of not having named parameters. And yes, it is comparatively ugly, as Robert and Michel's examples have very clearly shown. Also: The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. If by that, you meant that the caller is allowed to call the function without naming the parameters, I really don't see that as a problem. Yea, *maybe* it would be better if the callee could optionally decide caller must use named params, but even without that, it's a hell of a lot better than the current state, and it's also a lot better than Flag becase 1. It's *much* cleaner for both the caller and callee, and 2. It works for functions like foo(int, int, int, int), not just bools.
Re: Flag proposal
On 2011-06-10 12:47, KennyTM~ wrote: On Jun 11, 11 03:40, Jonathan M Davis wrote: On 2011-06-10 12:33, KennyTM~ wrote: On Jun 11, 11 03:30, Jonathan M Davis wrote: On 2011-06-10 09:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! I do have to admit that as much as I hate the idea of named parameters, this particular proposal certainly seems to be an argument in favor of adding them, which would tend to argue against making these changes. After thinking about it, I'd argue that it would be better to create a string mixin which created the enums for you instead of using the template as part of the arguments. e.g. mixin(YesNoEnum!KeepTerminator)); Then all of the rest of the code is the same. You'd still use KeepTerminator.yes and KeepTerminator.no, but we avoided having to create duplicate enums by hand every time that we want this kind of variable. So, you still reduce the boilerplate code, but the usage is much less ugly. - Jonathan M Davis The problem is the 'YesNoEnum!KeepTerminator' will not be shown along with the DDoc of 'getLine'. Why would it be? You generally want documentation specific to the enum anyway, so that isn't exactly boilerplate. You'd just stick the documentation above the mixin. And if you don't want to do that but want it in the documentation for the function that uses it (particularly if there's only one - though that's often not the case), then just put the documentation in the function's documentation. Andrei's current solution does nothing for documentation, and arguably makes it worse, because there's no place to put documentation on the enum directly if you need to. - Jonathan M Davis Please review the previous discussion of why Flag (was YesOrNo) was proposed. http://www.digitalmars.com/d/archives/digitalmars/D/YesOrNo_useful_idiom_he lper_or_wanking_134392.html In many cases, I very much think that the documentation should be separate. A prime example would be std.datetime.AllowDayOverflow. It's use in several places in std.datetime, and having one place to read up on it is definitely beneficial. Not having a place where the enum is defined separately would definitely be worse in that case. The area where it's more debatable is when there's only _one_ function which uses the enum. Then Andrei's proposed solution is more reasonable. But worse comes to worst, you can _still_ put the documentation with the function in the current solution. Andrei's solution adds _nothing_ to that. It just makes it so that there isn't actually a separate enum somewhere which can be documented. It removes the possibility of documenting it. I'd rather have the one line mixin which you can either document directly or skip documenting and put its documentation with the function that uses it rather than one where you _can't_ document it separately. std.datetime will _not_ switch to this even if it gets checked in simply because it will make the documentation worse. And I'm not sure that we want to have some enums using this solution and some not, since that would be inconsistent. I'm not entirely against Andrei's solution (it does reduce boilerplate code), but I think that a string mixin solution makes more sense. It's less verbose, and you can choose where to put its documentation. - Jonathan M Davis
Re: Flag proposal
On 6/10/11 1:52 PM, Robert Clipsham wrote: On 10/06/2011 19:06, Andrei Alexandrescu wrote: On 6/10/11 12:42 PM, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. This is not half-baked. It's pretty much it. My choice of wording was poor, sorry. Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. void foo(bool param, bool otherParam, bool thisOneIsntRequired = false); Call it with or without named parameters, two are required, one is not. foo(otherParam: true, param: false); foo(true, false); foo(otherParam: true, param: false, thisOneIsntRequired: true); Would all be valid. The second call is problematic because it still allows bad style in calls. Andrei
Re: [upforgrabs] tools/update
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:ist957$19nj$1...@digitalmars.com... We need a script to update all of dmd's paraphernalia. By this I'm putting the task up for grabs and am describing it. The script would require git to be installed, and would orchestrate git commands to freshen the installation. Either a tag can be given, or the script would automatically detect the latest semistable release, or even the script can be told to get the latest and greatest. The exact tagging convention is to be defined later. The trick with such tools is they must just work. That means wherever and however you installed dmd, the script should be able to detect everything it needs for a successful update. This means: dmd and rdmd binary locations, druntime and phobos library locations, and druntime and phobos import locations. I've already been planning to add the features of recompile DMD and check out DMD from git and compile it to DVM (unless Jacob plans to beat me to it). You do have good suggestions on some of the implementation details. If there's still another feature in your proposal that I've overlooked here, let me know. I was going to wait to do this until Jacob merged in my Windows pull request (he said he'd get to it end of next week, IIRC), because I want to base it off a DVM that already has Windows support, but maybe I shouldn't wait and should just fork my windows fork and get to it? (I'm still fairly new to DVCS and proper DVCS procedures.) DVM is written in D1/Tango, though. Would that be a problem? If so, and if Jacob doesn't have any objections to it being ported to D2/Phobos, then I'd volunteer to do the port. I already have experience porting a bunch of my own code from D1/Tango to D2/Phobos. But I don't want to be hasty about porting it: I assume Jacob had a reason for using D1/Tango. I don't know how important the reason was.
Re: Historical moment: D2 is now D
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:istj83$1rsa$1...@digitalmars.com... I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Thanks, Andrei So D2 becomes D. And D1 becomes D--. -=mike=-
Re: Available D2 implementation on Windows besides DMD?
Robert Clipsham rob...@octarineparrot.com wrote in message news:ist1af$tbj$1...@digitalmars.com... As for how well they optimize code, dmd has a state of the art optimizer from the 90s, or there abouts - the code it generates is pretty speedy, it has some obvious short comings though (I believe floating point and inlining are lacking, as well as some more modern optimizations). I'm pretty sure DMD does inlining. After all, it *does* have an -inline commandlne flag. My understanding is that it just doesn't always inline everything it could.
Re: Flag proposal
On 6/10/11 2:12 PM, Michel Fortin wrote: On 2011-06-10 14:52:53 -0400, Robert Clipsham rob...@octarineparrot.com said: On 10/06/2011 19:06, Andrei Alexandrescu wrote: Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I have to say I totally agree with Robert. I agree with the need for a way to name parameters, but instantiating a pseudo-boolean type from a template for each function parameter is worse than the initial problem. Templates are already a difficult concept to grasp for most people (because they're so abstract), we really don't need to replace every boolean parameter with a template type. I disagree with the templates are difficult mantra. It is a meme from C++ much like macros are evil are one from C. It's a simple construct, you use it. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. void foo(bool param, bool otherParam, bool thisOneIsntRequired = false); Call it with or without named parameters, two are required, one is not. foo(otherParam: true, param: false); foo(true, false); foo(otherParam: true, param: false, thisOneIsntRequired: true); And just try to think of the signature for the function above if it was using Flag! void foo(Flag!param param, Flag!otherParam otherParam, Flag!thisOneIsntRequired thisOneIsntRequired = Flag!thisOneIsntRequired.no); Do we really want to expose that in the documentation? Yes, that's the whole point, though I agree the hiccup in the default initializer is annoying. The documentation doesn't need the names anymore; the user would just say: void foo( Flag!compressed, Flag!encrypted, Flag!buffered = Flag!buffered.no); Save for the ehm default parameter this looks palatable to me. Andrei
Re: Available D2 implementation on Windows besides DMD?
On 2011-06-10 13:15, Nick Sabalausky wrote: Robert Clipsham rob...@octarineparrot.com wrote in message news:ist1af$tbj$1...@digitalmars.com... As for how well they optimize code, dmd has a state of the art optimizer from the 90s, or there abouts - the code it generates is pretty speedy, it has some obvious short comings though (I believe floating point and inlining are lacking, as well as some more modern optimizations). I'm pretty sure DMD does inlining. After all, it *does* have an -inline commandlne flag. My understanding is that it just doesn't always inline everything it could. dmd _definitely_ has inlining. It could use some improvement (e.g. functions with lazy parameters can't currently be inlined), but it _does_ have inlining. And dmd's optimizations aren't bad. It's just that they could be better. I expect that we'll see them improve further once the language has stablized more. As much as faster code would be nice, correct code is much more important. And there are still plenty of bugs to iron out in the compiler (though it's definitely improving). - Jonathan M Davis
Re: [OT] D's community is awesome!
Robert Clipsham rob...@octarineparrot.com wrote in message news:ist0iv$s2p$1...@digitalmars.com... PS Sorry if this doesn't read well, I replied from bottom to top :S Ahh, you must be one of those Forth coders.
Re: Flag proposal
On 6/10/11 9:47 PM, Nick Sabalausky wrote: I completely agree with Robert and Michel on all the points they've raised. Flag is admittedly a great example of the power of D's templates. And it's admittedly a very clever hack to get around *some* of the limitations of not having named parameters...*But* it's *still* just that: a hack to get around some of the limitations of not having named parameters. And yes, it is comparatively ugly, as Robert and Michel's examples have very clearly shown. Also: The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. If by that, you meant that the caller is allowed to call the function without naming the parameters, I really don't see that as a problem. Yea, *maybe* it would be better if the callee could optionally decide caller must use named params, but even without that, it's a hell of a lot better than the current state, and it's also a lot better than Flag becase 1. It's *much* cleaner for both the caller and callee, and 2. It works for functions like foo(int, int, int, int), not just bools. That quite accurately summarizes the reason for my short »I'm not really sure what to think about this – […] named parameters would be the better solution« comment on the pull request; full ack. David
Re: Historical moment: D2 is now D
Den 10-06-2011 19:06, Andrei Alexandrescu skrev: I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. This is great news! I guess the documentation for etc.curl is an error? /Jonas
Re: Flag proposal
On 6/10/11 2:30 PM, Jonathan M Davis wrote: On 2011-06-10 09:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! I do have to admit that as much as I hate the idea of named parameters, this particular proposal certainly seems to be an argument in favor of adding them, which would tend to argue against making these changes. There is general agreement (which includes myself) that a language feature is nicer than Flag, and that Flag is nicer than the current state of affairs. This is no surprise because a specialized language feature will _always_ be better than one built from tools offered within the language. It's like God vs. human. So the crucial question is whether a language change is warranted. We should be much more restrained than this discussion suggests. Any and all programming languages have limitations. This, coupled with the former point, leads to the fact that at some point you MUST look into doing within the language something that could be done nicer if you got to play God. Doing the latter does not scale. So, does Flag work around a limitation in the language? Sure. Would a language-changing solution work better? Absolutely. Is the necessity of changing the language a foregone conclusion? I don't think so. Andrei
Re: Flag proposal
2011/6/10 Andrei Alexandrescu seewebsiteforem...@erdani.org: On 6/10/11 1:52 PM, Robert Clipsham wrote: On 10/06/2011 19:06, Andrei Alexandrescu wrote: On 6/10/11 12:42 PM, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. This is not half-baked. It's pretty much it. My choice of wording was poor, sorry. Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. The problem that named parameters are still optional remains. Or we need to add one extra language feature to specify required named parameters. void foo(bool param, bool otherParam, bool thisOneIsntRequired = false); Call it with or without named parameters, two are required, one is not. foo(otherParam: true, param: false); foo(true, false); foo(otherParam: true, param: false, thisOneIsntRequired: true); Would all be valid. The second call is problematic because it still allows bad style in calls. Andrei I agree, introducing a syntax for required named parameters sounds like it would entail baggage of similar weight. Torarin
Re: Flag proposal
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:isttf6$2oub$1...@digitalmars.com... On 6/10/11 1:52 PM, Robert Clipsham wrote: On 10/06/2011 19:06, Andrei Alexandrescu wrote: On 6/10/11 12:42 PM, Robert Clipsham wrote: On 10/06/2011 17:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! Andrei I really *really* don't like this. It's ugly and verbose, and a pathetic work around for the lack of named parameters. Either support named parameters or not, don't have an ugly half-baked work-around. This is not half-baked. It's pretty much it. My choice of wording was poor, sorry. Ugly is in the eye of the beholder, but I fail to see how the added punctuation makes Flag!param.yes significantly more verbose than param : true. foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. I really see Flag more as a way to try to rationalize avoiding adding named parameters to the language. And yes, the legibility of foo(Flag!param.yes, Flag!otherParam.no);, combined with the frequency of need for such a thing, and the complete inability of Flag to address the problem for anything but bool, the inability to document it separately (as Jonathan Davis pointed out), is all definitely much much more than enough to warrant adding a tried-and-proven feature that's become standard in damn near every other modern language.
Re: Flag proposal
On 2011-06-10 16:10:51 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: On 6/10/11 2:12 PM, Michel Fortin wrote: I have to say I totally agree with Robert. I agree with the need for a way to name parameters, but instantiating a pseudo-boolean type from a template for each function parameter is worse than the initial problem. Templates are already a difficult concept to grasp for most people (because they're so abstract), we really don't need to replace every boolean parameter with a template type. I disagree with the templates are difficult mantra. It is a meme from C++ much like macros are evil are one from C. It's a simple construct, you use it. Neither C macros nor C++ or D templates are very difficult by themselves. People trying to do unintuitive but clever things with them earned them this reputation. If you want something to be used everywhere and it is not an implementation detail, make it part of the language. Implementing what sounds should be a language feature through a template hack and putting it the standard library is not going to make people feel good about the language, it'll remind them of what the language is missing. And just try to think of the signature for the function above if it was using Flag! void foo(Flag!param param, Flag!otherParam otherParam, Flag!thisOneIsntRequired thisOneIsntRequired = Flag!thisOneIsntRequired.no); Do we really want to expose that in the documentation? Yes, that's the whole point, though I agree the hiccup in the default initializer is annoying. I find it funny that you see a hiccup only in the default initializer when the name of all parameter is also duplicated in its type. Shouldn't that be 4 hiccups? The documentation doesn't need the names anymore; the user would just say: void foo( Flag!compressed, Flag!encrypted, Flag!buffered = Flag!buffered.no); Save for the ehm default parameter this looks palatable to me. Does that mean we now need a language feature to tell the documentation generator not to emit attribute names for parameters of type Flag! ? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Flag proposal
Nick Sabalausky a@a.a wrote in message news:istv62$2skn$1...@digitalmars.com... Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:isttf6$2oub$1...@digitalmars.com... On 6/10/11 1:52 PM, Robert Clipsham wrote: foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. I really see Flag more as a way to try to rationalize avoiding adding named parameters to the language. And yes, the legibility of foo(Flag!param.yes, Flag!otherParam.no);, combined with the frequency of need for such a thing, and the complete inability of Flag to address the problem for anything but bool, the inability to document it separately (as Jonathan Davis pointed out), is all definitely much much more than enough to warrant adding a tried-and-proven feature that's become standard in damn near every other modern language. Regarding the complete inability of Flag to address the problem for anything but bool, how are we going to wind up papering over that? Like: box(Int!x(3), Int!y(4), Int!width(100), Int!height(150), Int!depth(1), UInt!color(0xFFAA77)); ?
Re: Flag proposal
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:istulq$2rjc$1...@digitalmars.com... On 6/10/11 2:30 PM, Jonathan M Davis wrote: On 2011-06-10 09:15, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/94 Discuss! I do have to admit that as much as I hate the idea of named parameters, this particular proposal certainly seems to be an argument in favor of adding them, which would tend to argue against making these changes. There is general agreement (which includes myself) that a language feature is nicer than Flag, Much and that Flag is nicer than the current state of affairs. Only *barely*. This is no surprise because a specialized language feature will _always_ be better than one built from tools offered within the language. It's like God vs. human. So the crucial question is whether a language change is warranted. We should be much more restrained than this discussion suggests. Any and all programming languages have limitations. This, coupled with the former point, leads to the fact that at some point you MUST look into doing within the language something that could be done nicer if you got to play God. Doing the latter does not scale. So, does Flag work around a limitation in the language? Sure. Would a language-changing solution work better? Absolutely. Is the necessity of changing the language a foregone conclusion? I don't think so. In general, I would agree with this. I completely understand the desire, and even the need, to avoid extra language features when reasonable to do so. I really do. But the idea of using Flag over named parameters just stretches it to a rediculous extreme. This seriously reminds me of Sun's infamous whitepaper that desperately tried to rationalize Java's lack of delegates/anon-funcs (But you can use functors!!! Fuck functors.) Is adding the feature of named parameters worthwhile in light of Flag? *YES*, *ABSOLUTELY*, *CLEARLY*, *DEFINITELY*, *YES*, *YES*, *YES*.
Re: Flag proposal
On 6/10/11 3:30 PM, Nick Sabalausky wrote: I really see Flag more as a way to try to rationalize avoiding adding named parameters to the language. There are fights that I believe are important and others that I think are less so. I find name parameters nice to have but more in the second category. There's just so much stuff that's more important. And yes, the legibility of foo(Flag!param.yes, Flag!otherParam.no);, Fair point. I figured this should be easier: foo(yes!param, no!otherParam); See https://github.com/andralex/phobos/commit/84c75336a4ef04b4c3b1924d7ac9329e744ab8e7 combined with the frequency of need for such a thing, People have found 7 uses of the yes/no enum pattern in Phobos plus a couple others where it should - in 135KLoC. and the complete inability of Flag to address the problem for anything but bool, Flag can be made to incorporate arbitrary categorical types, I just haven't done that yet so as to not complicate implementation too early. the inability to document it separately (as Jonathan Davis pointed out), This is an issue shared by named parameters, and for such stuff the current enums work just fine. Now who is rationalizing? :o) is all definitely much much more than enough to warrant adding a tried-and-proven feature that's become standard in damn near every other modern language. I'm actually less convinced than before having read your arguments. Andrei
Re: Flag proposal
Andrei: We should be much more restrained than this discussion suggests. Any and all programming languages have limitations. This, coupled with the former point, leads to the fact that at some point you MUST look into doing within the language something that could be done nicer if you got to play God. Doing the latter does not scale. This use of word scale assumes there is a larger and larger group of basic features that we'll desire in the language. But I have experience both of normal languages and of languages with macros as Scheme, and I don't think this is true. In the next few years we will not want to add a large and growing number of basic features to D2/D3. And currently in D there are features much less generally useful than named arguments or tuple unpacking syntax sugar, as Delimited Strings, Lazy Variadic Functions and more. So, does Flag work around a limitation in the language? Sure. Would a language-changing solution work better? Absolutely. Is the necessity of changing the language a foregone conclusion? I don't think so. Named arguments offer a more general solution than Flags, useful for all kinds of arguments, with a more readable syntax. I don't think you need a sub-feature to _require_ the argument name at the call point (on the other hand you may desire a sub-feature Scala has, to support deprecation of argument names. This helps solve a problem Don too has with named arguments). Bye, bearophile
Re: Flag proposal
On 6/10/11 3:34 PM, Michel Fortin wrote: On 2011-06-10 16:10:51 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org said: On 6/10/11 2:12 PM, Michel Fortin wrote: I have to say I totally agree with Robert. I agree with the need for a way to name parameters, but instantiating a pseudo-boolean type from a template for each function parameter is worse than the initial problem. Templates are already a difficult concept to grasp for most people (because they're so abstract), we really don't need to replace every boolean parameter with a template type. I disagree with the templates are difficult mantra. It is a meme from C++ much like macros are evil are one from C. It's a simple construct, you use it. Neither C macros nor C++ or D templates are very difficult by themselves. People trying to do unintuitive but clever things with them earned them this reputation. See, here you're simply wrong. C macros are heinously complicated in definition, and heinously complicated to implement. C++ templates are very bulky in definition too. It's not worth your time you argue this further. If you want something to be used everywhere and it is not an implementation detail, make it part of the language. Implementing what sounds should be a language feature through a template hack and putting it the standard library is not going to make people feel good about the language, it'll remind them of what the language is missing. The problem with the hack label is that it instantly decreases the level of the conversation. It's the N word of programming. I don't want a universal thing, I want to solve a simple problem: there are 7 yes/no enums in Phobos, and probably some more to come. Flag solves that problem in a reasonable way. This is pretty much it. And just try to think of the signature for the function above if it was using Flag! void foo(Flag!param param, Flag!otherParam otherParam, Flag!thisOneIsntRequired thisOneIsntRequired = Flag!thisOneIsntRequired.no); Do we really want to expose that in the documentation? Yes, that's the whole point, though I agree the hiccup in the default initializer is annoying. I find it funny that you see a hiccup only in the default initializer when the name of all parameter is also duplicated in its type. Shouldn't that be 4 hiccups? I don't think so, but I understand how you can frame that as an argument that supports your viewpoint. The documentation doesn't need the names anymore; the user would just say: void foo( Flag!compressed, Flag!encrypted, Flag!buffered = Flag!buffered.no); Save for the ehm default parameter this looks palatable to me. Does that mean we now need a language feature to tell the documentation generator not to emit attribute names for parameters of type Flag! ? No, just version(ddoc) for select functions if you want them to. You have the needed means within the language. Andrei
Re: Flag proposal
On 2011-06-10 13:36, Nick Sabalausky wrote: Nick Sabalausky a@a.a wrote in message news:istv62$2skn$1...@digitalmars.com... Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:isttf6$2oub$1...@digitalmars.com... On 6/10/11 1:52 PM, Robert Clipsham wrote: foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. I really see Flag more as a way to try to rationalize avoiding adding named parameters to the language. And yes, the legibility of foo(Flag!param.yes, Flag!otherParam.no);, combined with the frequency of need for such a thing, and the complete inability of Flag to address the problem for anything but bool, the inability to document it separately (as Jonathan Davis pointed out), is all definitely much much more than enough to warrant adding a tried-and-proven feature that's become standard in damn near every other modern language. Regarding the complete inability of Flag to address the problem for anything but bool, how are we going to wind up papering over that? Like: box(Int!x(3), Int!y(4), Int!width(100), Int!height(150), Int!depth(1), UInt!color(0xFFAA77)); These yes/no enums _aren't_ named arguments. They're an attempt at creating new types where the values say what they are. The goal is primarily clarity, which named arguments arguably help with, but it's not quite the same thing. Without typedef (which is on its way out), you can't really do something like that with anything other than bool. Int!y(4) has to generate an int (unless you want to be forcing that all of these arguments be structs, which would be hideous), at which point it's purely documentation which the compiler has to optimize out. It's not doing the same thing as Flag at all. Andrei isn't trying to create general named arguments here. He's simply trying to create a cleaner way of generating enums with yes and no values and thus reduce boilerplate code. Having named arguments would create a similar effect, but the goal of this enum has nothing to do with named arguments beyond the fact that they have a similar effect. Its goal is to reduce boilerplate code. The net result of having the enums and Flag _is_ similar to named arguments for bool, but I don't believe that Andrei ever set down this path with the idea of creating named arguments. He effectively wanted a typedef for bool which was self-documenting. So, your suggestions of Int!height(150) and the like are trying to do something very different (albeit somewhat related) to what Flag is trying to do. - Jonathan M Davis
Re: Article discussing Go, could well be D
Jeff Nowakowski j...@dilacero.org wrote in message news:ist8n0$1952$1...@digitalmars.com... You still didn't need to pass judgment on what is notable or not in their later careers. Why the hell can't I? Is there some thought police I don't know about? *He* passed judgement on the guy's earlier career. And *you* said Maybe because he has done things of note since? so clearly, *you're* passing judgement on his later career. Oh, I see, passing judgement is only ok when the verdict happens to be thumbs up... If you're unimpressed with something then that's passing judgement, but if you are impressed then that's not a judgement at all. What the hell did I step into, some New Age/Flower Child-Bizarro-World where only positive uplifting ideas are valid ones? Bunch of hippocritical bullcrap. It's enough to say that dismissing D as being irrelevant without justification is the problem. Also, there's nothing wrong with taking a look at a C-like language because the inventors were heavily involved with the original C and Unix environments. Much like people are encouraged to look at D because of Walter's past work with a C++ compiler and Andrei's C++ experience. As a way to pique interest, it's valid. However, that should not be a determination of a language's actual merit. Perhaps, but that's not the full extent of the situation here. He labeled D as stay[ing] in the spheres of irrelevancy, and the *only* conceivable reason for him to have made such an assesement is that D lacks Go's Google, Pike, and Thompson. I'm not allowed to be annoyed by that and voice my reasons?
Re: Historical moment: D2 is now D
On Fri, 10 Jun 2011 16:11:34 -0400, Mike James f...@bar.com wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:istj83$1rsa$1...@digitalmars.com... I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Thanks, Andrei So D2 becomes D. And D1 becomes D--. D0 Seriously though, I'm not sure why we have to do this... It's weird to have D1 and D. To me, D1 D, like in D, D1, D2, D3 I hope this pattern doesn't continue for D3 (well, actually, would that then be D2?) Why can't D2 be D version 2, and D1 be D version 1, where both languages are the D programming language? It's how other languages do things (C#, php, python, etc.). -Steve
Re: Flag proposal
On 6/10/11 3:36 PM, Nick Sabalausky wrote: Nick Sabalauskya@a.a wrote in message news:istv62$2skn$1...@digitalmars.com... Andrei Alexandrescuseewebsiteforem...@erdani.org wrote in message news:isttf6$2oub$1...@digitalmars.com... On 6/10/11 1:52 PM, Robert Clipsham wrote: foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. I really see Flag more as a way to try to rationalize avoiding adding named parameters to the language. And yes, the legibility of foo(Flag!param.yes, Flag!otherParam.no);, combined with the frequency of need for such a thing, and the complete inability of Flag to address the problem for anything but bool, the inability to document it separately (as Jonathan Davis pointed out), is all definitely much much more than enough to warrant adding a tried-and-proven feature that's become standard in damn near every other modern language. Regarding the complete inability of Flag to address the problem for anything but bool, how are we going to wind up papering over that? Like: box(Int!x(3), Int!y(4), Int!width(100), Int!height(150), Int!depth(1), UInt!color(0xFFAA77)); ? I don't find it entirely fair to demean the suggestion as a tool to sustain your viewpoint. Flag supporting only yes and no is not a complete inability - it is its charter. The plan is not to have Flag be a replacement for named arguments, but instead to have it support good practices for Boolean settings and replace a number of awkward enum definitions in Phobos. As I mentioned, in the future it's possible to have Flag (or a related abstraction) support categorical features beyond yes and no, but it is not meant, and does not attempt, to cover named arguments. Andrei
Re: Historical moment: D2 is now D
On 6/10/11 4:06 PM, Steven Schveighoffer wrote: On Fri, 10 Jun 2011 16:11:34 -0400, Mike James f...@bar.com wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:istj83$1rsa$1...@digitalmars.com... I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Thanks, Andrei So D2 becomes D. And D1 becomes D--. D0 Seriously though, I'm not sure why we have to do this... It's weird to have D1 and D. To me, D1 D, like in D, D1, D2, D3 I hope this pattern doesn't continue for D3 (well, actually, would that then be D2?) Why can't D2 be D version 2, and D1 be D version 1, where both languages are the D programming language? It's how other languages do things (C#, php, python, etc.). -Steve D is D. Andrei
Re: Flag proposal
Nick Sabalausky wrote: Nick Sabalausky a@a.a wrote in message news:istv62$2skn$1...@digitalmars.com... Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:isttf6$2oub$1...@digitalmars.com... On 6/10/11 1:52 PM, Robert Clipsham wrote: foo(param: true, otherParam: false); foo(Flag!param.yes, Flag!otherParam.no); I don't know about you, but I find the former is far more legible. I'd hate to see my code littered with Flag!something. I agree it's more legible. The crucial question is whether the added legibility warrants adding a new feature to the language. I really see Flag more as a way to try to rationalize avoiding adding named parameters to the language. I don't, even though I like named parameters. boolean parameters for binary options are kind of an exception imho, because they decrease readability at the call site much more often than other types do. Somebody one this newsgroup - maybe it was Don Clugston, also made a good point against named parameters: it introduces inflexibility because now the names of the parameters of a function become part of the public api. Changing a name will now break client code. I'd still probably welcome named parameters though. And yes, the legibility of foo(Flag!param.yes, Flag!otherParam.no);, combined with the frequency of need for such a thing, and the complete inability of Flag to address the problem for anything but bool, the inability to document it separately (as Jonathan Davis pointed out), is all definitely much much more than enough to warrant adding a tried-and-proven feature that's become standard in damn near every other modern language. Regarding the complete inability of Flag to address the problem for anything but bool, how are we going to wind up papering over that? Like: box(Int!x(3), Int!y(4), Int!width(100), Int!height(150), Int!depth(1), UInt!color(0xFFAA77)); ?
Re: [OT] D's community is awesome!
Trass3r wrote: Am 10.06.2011, 13:48 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com: You're probably better off for it - I used to be strongly in the mercurial camp, but having used git for a while I find I vastly prefer it, despite still not knowing how to do quite a bit with it. Yep, Mercurial's biggest drawback imo is that bookmarks (which let you do something analogous to git's branches) aren't standard and thus aren't pushed/pulled by default. Bookmarks are local by definition. If you want the same functionality that can be pushed/pulled, you should use branches. Or did I miss something? Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Flag proposal
Andrei: I don't want a universal thing, I want to solve a simple problem: there are 7 yes/no enums in Phobos, and probably some more to come. Flag solves that problem in a reasonable way. This is pretty much it. I didn't understand this well at first. Thank you for explaining again. Bye, bearophile
Re: Flag proposal
On 6/10/11, Lutger Blijdestijn lutger.blijdest...@gmail.com wrote: Changing a name will now break client code. The flag template suffers from the same issue.
Re: Article discussing Go, could well be D
Jeff Nowakowski j...@dilacero.org wrote in message news:ist7oe$17ge$1...@digitalmars.com... On 06/09/2011 03:27 AM, Nick Sabalausky wrote: Once again, I wasn't Pike-bashing. You're misinterpreting my words and assuming I did. Billions of people, obviously myself included, have never done *anything* of real significant note whether recently or 800 years ago. And everyone knows that. So how the heck can saying some guy who did something significant 40 years ago and hasn't done a damn thing of note since even *possibly* be taken as an insult? Maybe because he has done things of note since? Who is it for you to judge? And then comparing him against Andrei, to boot. I don't want to get into a debate on his career, or turn this into an Andre vs Pike flamefest, so I won't drag up what people have worked on. My point is you didn't have to go there. Yea, I didn't *have* to go there. I don't *have* post anything here at all. So what? That obviously that doesn't imply that I can't or shouldn't. Yes, what you did was inflammatory and ad hominem. No, what I'm starting to do *now* is inflammatory. What I did before is make an observational statement which you twisted around into a condemnation. If I made a statement about someone (who apperently seems to be some demigod) and that statement that didn't involve any gushing over the guy, then tough shit, them's the breaks. As for ad hominem, you don't seem to even understand the concept. What makes something an ad hominem fallacy is assigning truth value based on *who* agrees with, disagrees with, or is otherwise associated with it. What *I* did was make a statement *about* a person. No, that is *not* an ad hominem fallacy. And no, just because it wasn't a *good* statement doesn't imply it was a *bad* statement. And even if it *were* a bad statement, which it clearly wasn't, I don't have to be an elected or appointed judge, or God, or anything like that to be entited to have that viewpoint and voice it.
Re: Article discussing Go, could well be D
On 6/10/11 4:08 PM, Nick Sabalausky wrote: Jeff Nowakowskij...@dilacero.org wrote in message news:ist8n0$1952$1...@digitalmars.com... You still didn't need to pass judgment on what is notable or not in their later careers. Why the hell can't I? Is there some thought police I don't know about? *He* passed judgement on the guy's earlier career. And *you* said Maybe because he has done things of note since? so clearly, *you're* passing judgement on his later career. Oh, I see, passing judgement is only ok when the verdict happens to be thumbs up... Fair point. It corroborates well with the advice I got from a specialist in public speaking - avoid saying Good question in preface to your response to a question. His argument was that that's a signal you pass judgment on the question itself (albeit positively), and others may feel uncomfortable that you'd judge their own question poorly. Anyway, perhaps it's not worth to escalate this any further. My opinion (judgment :o)) is that there are things one says over a beer to a friend, things that one says to a near-stranger (notorious or not) in a social setting, and things that one shares on the net. I think it's reasonable to ascribe to human nature that the three sets are different without a thought police being necessary. Andrei
Re: [OT] D's community is awesome!
Trass3r u...@known.com wrote in message news:op.vwu1q2lv3ncmek@enigma... Am 10.06.2011, 13:48 Uhr, schrieb Robert Clipsham rob...@octarineparrot.com: You're probably better off for it - I used to be strongly in the mercurial camp, but having used git for a while I find I vastly prefer it, despite still not knowing how to do quite a bit with it. Yep, Mercurial's biggest drawback imo is that bookmarks (which let you do something analogous to git's branches) aren't standard and thus aren't pushed/pulled by default. Isn't cloning a sufficient equivalent to git's branches? And of course github is way better than bitbucket, but that's not Mercurial's fault I admit. Totally agree. Not that I'm big fan of GitHub, but yea, definitely better than BitBucket.
Re: Flag proposal
On 6/10/11 4:28 PM, Andrej Mitrovic wrote: On 6/10/11, Lutger Blijdestijnlutger.blijdest...@gmail.com wrote: Changing a name will now break client code. The flag template suffers from the same issue. Actually, not. The name used with Flag is part of its type. Even in a separate compilation approach, the type names must match, which is not the case for parameter names. Andrei
Re: Historical moment: D2 is now D
On 2011-06-10 14:06, Steven Schveighoffer wrote: On Fri, 10 Jun 2011 16:11:34 -0400, Mike James f...@bar.com wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:istj83$1rsa$1...@digitalmars.com... I think we all agree that it is appropriate to characterize D2 to mean The D Programming Language. From here on, we have changed the website http://d-programming-language.org to reflect that reality. D simply refers to what was formerly known as D2, and D1 stays D1. Also, today Walter will change the D links from digitalmars.com to point to http://d-programming-language.org, which is now the official site of the D programming language. Expect (and please contribute) many improvements of that site going forward. Thanks, Andrei So D2 becomes D. And D1 becomes D--. D0 Seriously though, I'm not sure why we have to do this... It's weird to have D1 and D. To me, D1 D, like in D, D1, D2, D3 I hope this pattern doesn't continue for D3 (well, actually, would that then be D2?) Why can't D2 be D version 2, and D1 be D version 1, where both languages are the D programming language? It's how other languages do things (C#, php, python, etc.). D is the programming language. There are multiple versions of it. Currently, we have versions 1 and 2, which are typically referred to as D1 and D2. D2 is the most recent - and therefore current - version, whereas D1 is the previous version. On the main site, we're choosing to generally mean D2 when we refer to D and specifically say D1 when referring to stuff which is specific to D1. Presumably, if and when there is D3 and it becomes appropriatey stable to be considered the current version of the language, then D3 will be referred to as D, and the term D2 will be used when referring to something which is specific to D2. It's quite typical when talking about other languages (C#, Java, python, etc.) to not be particularly specific about version numbers when talking about the language. When using the language's name without a version number, you're generally either referring to the language as a whole or to the latest version. We're just going to be doing the same on D's official site. The term D2 will still be used if we need to be specific about versions, but in general, we're talking about the most recent version of the language when talking about D, so we're just calling it D. I don't see anything odd about that. - Jonathan M Davis
