Re: hello world in D

On 5/31/13 12:48 PM, Joseph Rushton Wakeling wrote: On 05/31/2013 06:34 PM, Brad Anderson wrote: On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote: Why copyright 2012 not a 2013? Fixed in git. Is this not something where some clever CTFE could be used to swipe the date of build and in

minifying the website

Hello, I've been looking through the logs and it looks like the top files in bytes transferred yesterday (even with the deluge of downloads) were a number of Javascript, HTML, and CSS files. There are programs to reduce the size of such files called "minifiers". Should we use some? If so, w

Re: A simple way to do compile time loop unrolling

Am Fri, 31 May 2013 16:33:19 +0200 schrieb Piotr Szturmaj : > It is also an opportunity to do loop vectorization. But I > doubt that either is available in DMD, not sure about GDC and LDC. GDC once vectorized something for me, where I used a struct of 4 ubyte fields. I don't remember if it was a

Re: hello world in D

On Friday, May 31, 2013 18:05:16 Rob T wrote: > I've seen this happen with 2.062, if you take out -noboundscheck > it may reduce the size significantly and compile a lot faster. > Makes no sense. My first guess would be that more ends up being inlined with -noboundscheck due to the differences in

Re: D on next-gen consoles and for game development

On 05/24/2013 01:51 AM, Joseph Rushton Wakeling wrote: > Maybe someone else can point to an example, but I can't think of any language > prior to D that has both the precision and speed to be useful for games and > embedded programming, and that also has GC built in. > > So it seems to me that thi

Re: hello world in D

On 05/31/2013 06:34 PM, Brad Anderson wrote: > On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote: >> Why copyright 2012 not a 2013? > > Fixed in git. Is this not something where some clever CTFE could be used to swipe the date of build and insert the correct year? :-P

Re: Slow performance compared to C++, ideas?

On 05/31/2013 05:12 PM, bearophile wrote: > There are many kinds of D code, not everything is a high performance > ray-tracer > or 3D game. So I'm sure there are many many situations where using the C++ STL > is more than enough. As most tools, you need to know where and when to use > them. > So

Re: The stately := operator feature proposal

The := syntax looks just like the += *= ~= syntax, which has completely different meanings, so for some people it will only serve to confuse them more than they already are. BTW D does have instances of multiple ways of doing the same things. Eg private: int x = 1; private int x = 1; p

Re: hello world in D

On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote: [snip] Even, when I type dmd -v : DMD32 D Compiler v2.063 Copyright (c) 1999-2012 by Digital Mars written by Walter Bright Documentation: http://dlang.org/ - Why copyright 2012 not a 2013? Fixed

Re: hello world in D

On Fri, 31 May 2013 16:58:11 +0100, Craig Dillabaugh wrote: Under 40 kilobytes! If you do the bare minimum you can get down to about 1 KB, but at that point, you're actually writing in mostly (inline) assembly rather than D. The code in the link though supports a majority (though certa

Re: Slow performance compared to C++, ideas?

On Friday, May 31, 2013 19:42:55 Manu wrote: > On 31 May 2013 14:06, deadalnix wrote: > > On Friday, 31 May 2013 at 02:56:25 UTC, Andrei Alexandrescu wrote: > >> On 5/30/13 9:26 PM, finalpatch wrote: > >>> https://dl.dropboxusercontent.**com/u/974356/raytracer.d >>> boxuserconten

Re: hello world in D

On Friday, 31 May 2013 at 15:58:12 UTC, Craig Dillabaugh wrote: Do you really think that is such a big issue? I can't remember the last time I looked at the size of an executable I generated. There's three cases where I sometimes care: 1) if I build the program on my computer, then push it to

Re: 2.063 release

On 5/31/13 8:52 AM, David Nadlinger wrote: On Thursday, 30 May 2013 at 20:13:14 UTC, Andrei Alexandrescu wrote: I am the one who switched to download over HTTP. The reason is that I hadn't anticipated the enormous demand following the announcement, and we really need to collect download statis

Re: D on next-gen consoles and for game development

On 31.05.2013 12:54, Michel Fortin wrote: On 2013-05-31 06:02:20 +, Rainer Schuetze said: On 30.05.2013 22:59, Benjamin Thaut wrote: One possible complication: memory block operations would have to treat pointer fields differently somehow. Would they? Shouldn't it be possible to make

Re: hello world in D

I've seen this happen with 2.062, if you take out -noboundscheck it may reduce the size significantly and compile a lot faster. Makes no sense. --rt

Re: hello world in D

Under 40 kilobytes! If you do the bare minimum you can get down to about 1 KB, but at that point, you're actually writing in mostly (inline) assembly rather than D. The code in the link though supports a majority (though certainly not all) of D's features. Agreed 100%. But newcomers don't

Re: 2.063 release

On Thursday, 30 May 2013 at 20:13:14 UTC, Andrei Alexandrescu wrote: I am the one who switched to download over HTTP. The reason is that I hadn't anticipated the enormous demand following the announcement, and we really need to collect download statistics, which are already built in dlang.org.

Re: A simple way to do compile time loop unrolling

Andrei Alexandrescu: We should have something like that in phobos. Better (some part of static foreach): http://d.puremagic.com/issues/show_bug.cgi?id=4085 Bye, bearophile

Re: The stately := operator feature proposal

On 05/31/2013 02:58 PM, Dicebot wrote: > I really hope such stuff will _never ever_ get into official D spec. It is > just > going to be a disaster for language that aims to be general-purpose and > doesn't > want to die because of minor detail overload complexity, like C++ did. > > That syntax

Re: hello world in D

On Friday, 31 May 2013 at 15:03:58 UTC, Regan Heath wrote: It is a bit surprising isn't it. Aye. BTW if you want to get into really small, statically linked D programs, you can do a custom druntime, no phobos, no C lib, with just the code you want. I recently wrote about a toy I've been pla

Re: Slow performance compared to C++, ideas?

Manu: Frankly, this is a textbook example of why STL is the spawn of satan. For some reason people are TAUGHT that it's reasonable to write code like this. There are many kinds of D code, not everything is a high performance ray-tracer or 3D game. So I'm sure there are many many situations

Re: hello world in D

On Friday, 31 May 2013 at 14:56:17 UTC, khurshid wrote: i.e. 299 Kbyte. yeah it varies a bit by computer and 32 bit vs 64 bit etc, but same ballpark. Why copyright 2012 not a 2013? Walter probably just forgot to update the message.

Re: Slow performance compared to C++, ideas?

On Fri, 31 May 2013 10:49:21 -0400, Andrei Alexandrescu wrote: On 5/31/13 9:07 AM, finalpatch wrote: D is very strong at TMP, it provides a lot more tools specifically designed for TMP, that is vastly superior than C++ which relies on abusing the templates. This is actually the main reason d

Re: hello world in D

On Fri, 31 May 2013 16:00:00 +0100, Adam D. Ruppe wrote: On Friday, 31 May 2013 at 14:48:12 UTC, Regan Heath wrote: You will get a similar size (or greater) if you statically link the stdc library. That's not necessarily true because static linking only pulls functions that are actually

Re: Slow performance compared to C++, ideas?

Manu: Yeah, I've actually noticed this too on a few occasions. It would be nice if array operations would unroll for short arrays. Particularly so for static arrays! Thanks to Kenji the latest dmd 2.063 solves part of this problem: http://d.puremagic.com/issues/show_bug.cgi?id=2356 Maybe thi

Re: hello world in D

On Friday, 31 May 2013 at 14:48:12 UTC, Regan Heath wrote: You will get a similar size (or greater) if you statically link the stdc library. That's not necessarily true because static linking only pulls functions that are actually used by the program even though I just tried gcc hello.c

Re: hello world in D

On Friday, 31 May 2013 at 14:48:02 UTC, Adam D. Ruppe wrote: If you use printf instead of std.stdio, you'll save about 150 KB in the executable import core.stdc.stdio; void main() { printf("hello\n"); } $ dmd test2.d $ ls -lh test2 -rwxr-xr-x 1 me users 287K 2013-05-31 10:40 test2 $

Re: A simple way to do compile time loop unrolling

On 5/31/13 10:06 AM, finalpatch wrote: Just want to share a new way I just discovered to do loop unrolling. template Unroll(alias CODE, alias N) { static if (N == 1) enum Unroll = format(CODE, 0); else enum Unroll = Unroll!(CODE, N-1)~format(CODE, N-1); } after that you can write stuff like mi

Re: Slow performance compared to C++, ideas?

Namespace: I thought GDC or LDC have something like: float[$] v = [x, x, x]; which is converted to flot[3] v = [x, x, x]; Am I wrong? DMD need something like this too. Right. Vote (currently only 6 votes): http://d.puremagic.com/issues/show_bug.cgi?id=481 Bye, bearophile

Template expansion bug?

While doing some testing, I came across this behavior: template foo(T) { void foo() {} } void main() { foo!(int).foo(); //foo!(int)(); // this works } Error: testbug.d(7): Error: template testbug.foo does not match any function template declaration. Candidates are: testbug.d(1):

Re: Slow performance compared to C++, ideas?

On 5/31/13 9:07 AM, finalpatch wrote: D is very strong at TMP, it provides a lot more tools specifically designed for TMP, that is vastly superior than C++ which relies on abusing the templates. This is actually the main reason drawing me to D: TMP in a more pleasant way. IMO one thing D needs to

Re: hello world in D

On Fri, 31 May 2013 15:33:46 +0100, khurshid wrote: I just download dmd 2.063, and compile simple "hello world" program: // hello.d import std.stdio; int main() { writeln("hello world"); return 0; } with -O -release -inline -noboundscheck flags. And size of result output file

Re: hello world in D

On Friday, 31 May 2013 at 14:33:48 UTC, khurshid wrote: And size of result output file 'hello' equal to 1004.1 Kbyte Whoa, that's up like several times from the last dmd release you can get down to 600 kb or so by not using the flags. Strange, combining all those flags increases the siz

hello world in D

I just download dmd 2.063, and compile simple "hello world" program: // hello.d import std.stdio; int main() { writeln("hello world"); return 0; } with -O -release -inline -noboundscheck flags. And size of result output file 'hello' equal to 1004.1 Kbyte !!! Why size is big? I'm

Re: A simple way to do compile time loop unrolling

W dniu 31.05.2013 16:06, finalpatch pisze: Just want to share a new way I just discovered to do loop unrolling. template Unroll(alias CODE, alias N) { static if (N == 1) enum Unroll = format(CODE, 0); else enum Unroll = Unroll!(CODE, N-1)~format(CODE, N-1); } after t

Re: A simple way to do compile time loop unrolling

Minor improvement: template Unroll(alias CODE, alias N, alias SEP="") { static if (N == 1) enum Unroll = format(CODE, 0); else enum Unroll = Unroll!(CODE, N-1, SEP)~SEP~format(CODE, N-1); } So vector dot product can be unrolled like this: mixin(Unroll!("v1[%1$d]*v2[%1$

Re: Template args to UDA's

On Fri, 31 May 2013 06:47:07 -0400, Timon Gehr wrote: @attribute("target", T) void func(string T)() {} would simply need to be treated like: template func(string T){ @attribute("target", T) void func() {} } In fact, today's current semantics suggest this is exactly what happens: impor

A simple way to do compile time loop unrolling

Just want to share a new way I just discovered to do loop unrolling. template Unroll(alias CODE, alias N) { static if (N == 1) enum Unroll = format(CODE, 0); else enum Unroll = Unroll!(CODE, N-1)~format(CODE, N-1); } after that you can write stuff like mixin(Unroll!("v[

Re: Inability to dup/~ for const arrays of class objects

On Fri, 31 May 2013 00:48:47 -0400, Peter Williams wrote: On 31/05/13 12:07, Steven Schveighoffer wrote: On Thu, 30 May 2013 20:05:59 -0400, Peter Williams wrote: On 30/05/13 16:21, Ali Çehreli wrote: On 05/29/2013 06:54 PM, Peter Williams wrote: > I find the mechanism described in the

Re: Slow performance compared to C++, ideas?

On 31 May 2013 23:07, finalpatch wrote: > I actually have some experience with C++ template > meta-programming in HD video codecs. My experience is that it is > possible for generic code through TMP to match or even beat hand > written code. Modern C++ compilers are very good, able to > optimize

Re: I was wrong

On Fri, 31 May 2013 04:38:10 -0400, Jacob Carlborg wrote: On 2013-05-30 21:44, Timothee Cour wrote: shall we have both the current changelog for all releases + individual changelogs per release changelog.html // always latest version only; people go there by default changelog_all.html //same

Re: Slow performance compared to C++, ideas?

I actually have some experience with C++ template meta-programming in HD video codecs. My experience is that it is possible for generic code through TMP to match or even beat hand written code. Modern C++ compilers are very good, able to optimize away most of the temporary variables resulting very

Re: Slow performance compared to C++, ideas?

On Friday, 31 May 2013 at 11:49:05 UTC, Manu wrote: I find that using templates actually makes it more likely for the compiler to properly inline. But I think the totally generic expressions produce cases where the compiler is considering too many possibilities that inhibit many optimisations.

Re: The stately := operator feature proposal

On Thursday, 30 May 2013 at 23:50:40 UTC, Jonathan M Davis wrote: There are orders of magnitudes of difference between providing a new abstraction like a class and simply rewriting auto i = foo; as i := foo; _All_ it does is save you 4 characters and shift where in the statement the piece

Re: Slow performance compared to C++, ideas?

On 05/31/2013 01:48 PM, Manu wrote: > I find that using templates actually makes it more likely for the compiler to > properly inline. But I think the totally generic expressions produce cases > where > the compiler is considering too many possibilities that inhibit many > optimisations. > It mig

Re: The stately := operator feature proposal

On Friday, 31 May 2013 at 00:50:56 UTC, bearophile wrote: Manu: I've raised the topic of multiple-return-values a whole heap of times. It's usually shot down because it would create ambiguities in existing syntax. Solving only that small problem is a bad idea. A language meant to support so

Re: Slow performance compared to C++, ideas?

On 31 May 2013 21:05, Timon Gehr wrote: > On 05/31/2013 12:58 PM, Joseph Rushton Wakeling wrote: > >> On 05/31/2013 08:34 AM, Manu wrote: >> >>> What's taking the most time? >>> The lighting loop is so template-tastic, I can't get a feel for how fast >>> that >>> loop would be. >>> >> >> Hah, I f

Re: Slow performance compared to C++, ideas?

On 31 May 2013 20:58, Joseph Rushton Wakeling wrote: > On 05/31/2013 08:34 AM, Manu wrote: > > What's taking the most time? > > The lighting loop is so template-tastic, I can't get a feel for how fast > that > > loop would be. > > Hah, I found this out the hard way recently -- have been doing some

Re: Slow performance compared to C++, ideas?

On 05/31/2013 01:05 PM, Timon Gehr wrote: > That wouldn't make any sense though, since after template expansion there is > no > difference between the generated version and a particular handwritten version. That's what I'd assumed too, but there _is_ a speed difference. I'm open to suggestions a

Aftershock of 2.063 release

Given the release of 2.063, it would be good to upgrade. Clearly I could download the deb and rpm files and put them in my local repository. However, there is the D APT repository and it seems good to use this instead for Debian. I wonder if it would be a good idea for people interested in Debian

Re: Slow performance compared to C++, ideas?

On 05/31/2013 12:58 PM, Joseph Rushton Wakeling wrote: On 05/31/2013 08:34 AM, Manu wrote: What's taking the most time? The lighting loop is so template-tastic, I can't get a feel for how fast that loop would be. Hah, I found this out the hard way recently -- have been doing some experimental

Re: Will I try again? and also C header files.

On Friday, 31 May 2013 at 07:18:38 UTC, SeanVn wrote: I hope now things have settled down. They have, considerably. I will look at the language for a couple of days. I presume I now only have to look at D2 and Phobos and not the previous 4 way split of D1/D2/Phobos/Tango. Correct I hav

Re: Slow performance compared to C++, ideas?

On 05/31/2013 08:34 AM, Manu wrote: > What's taking the most time? > The lighting loop is so template-tastic, I can't get a feel for how fast that > loop would be. Hah, I found this out the hard way recently -- have been doing some experimental reworking of code where some key inner functions were

Re: Template args to UDA's

* fix = fit On 31 May 2013 20:56, Manu wrote: > On 31 May 2013 20:47, Timon Gehr wrote: > >> On 05/28/2013 05:45 PM, Kenji Hara wrote: >> >>> It looks reasonable, but in general case it would introduce not trivial >>> semantic issue. >>> >>> Based on the current D language spec, prefix attribu

Re: Template args to UDA's

On 31 May 2013 20:47, Timon Gehr wrote: > On 05/28/2013 05:45 PM, Kenji Hara wrote: > >> It looks reasonable, but in general case it would introduce not trivial >> semantic issue. >> >> Based on the current D language spec, prefix attribute is just rewritten >> to blocked attribute. >> >> @attrib

Re: D on next-gen consoles and for game development

On 2013-05-31 06:02:20 +, Rainer Schuetze said: On 30.05.2013 22:59, Benjamin Thaut wrote: One possible complication: memory block operations would have to treat pointer fields differently somehow. Would they? Shouldn't it be possible to make this part of the post-blit constructor? Not

Re: Template args to UDA's

On 05/28/2013 05:45 PM, Kenji Hara wrote: It looks reasonable, but in general case it would introduce not trivial semantic issue. Based on the current D language spec, prefix attribute is just rewritten to blocked attribute. @attribute("target", T) void func(string T)() {} to: @attribute("targ

Re: Slow performance compared to C++, ideas?

On Friday, 31 May 2013 at 04:06:58 UTC, deadalnix wrote: I don't think going as far as making thing final by default make sense at this point. But we sure need a way to be able to finalize methods. We had an extensive discussion with Don and Manu at DConf, here are some idea that came out :

Re: Why UTF-8/16 character encodings?

On Fri, 31 May 2013 07:57:37 +0200, Walter Bright wrote: On 5/30/2013 5:00 PM, Peter Williams wrote: On 31/05/13 05:07, Walter Bright wrote: On 5/30/2013 4:24 AM, Manu wrote: We don't all know English. Plenty of people don't. I've worked a lot with Sony and Nintendo code/libraries, for ins

Re: Slow performance compared to C++, ideas?

On 31 May 2013 14:06, deadalnix wrote: > On Friday, 31 May 2013 at 02:56:25 UTC, Andrei Alexandrescu wrote: > >> On 5/30/13 9:26 PM, finalpatch wrote: >> >>> https://dl.dropboxusercontent.**com/u/974356/raytracer.d >>> https://dl.dropboxuser

Re: I was wrong

On Friday, 31 May 2013 at 08:45:08 UTC, Dicebot wrote: On Thursday, 30 May 2013 at 18:06:03 UTC, Walter Bright wrote: about the changelog. Andrej Mitrovic has done a super awesome job with the changelog, and it is paying off big time. I am very happy to be proven wrong about it. It is so goo

Re: Slow performance compared to C++, ideas?

On Friday, 31 May 2013 at 05:49:55 UTC, finalpatch wrote: Thanks Nazriel, It is very cool you are able to narrow the gap to within 1.5x of c++ with a few simple changes. I checked your version, there are 3 changes (correct me if i missed any): * Change the (float) constructor from v= [x,x,

Re: Slow performance compared to C++, ideas?

On 2013-05-31 06:06, deadalnix wrote: - Introduce a virtual keyword. Virtual by default isn't such a big deal if you can do final: and reverse the default behavior. However, once you key in the final land, you are trapped here, you can't get out. Introducing a virtual keyword would allow for

Re: 2.063 release

On Friday, 31 May 2013 at 08:38:47 UTC, Andrea Fontana wrote: Why not, for example, mega.co.nz? Blazing fast and free. Am I missing something? Using common file share services to distribute an official release is bad for reputation. As a mirror at most.

Re: Will I try again? and also C header files.

On 2013-05-31 09:18, SeanVn wrote: I looked at the D programming language a few years ago and though it was good. Then I ran into trouble. The language was in a state of flux. I would write code and with the next version of D it would no longer work. The same thing was happening to people who

Re: 2.063 release

On Friday, 31 May 2013 at 08:42:38 UTC, Dicebot wrote: On Friday, 31 May 2013 at 08:38:47 UTC, Andrea Fontana wrote: Why not, for example, mega.co.nz? Blazing fast and free. Am I missing something? Using common file share services to distribute an official release is bad for reputation. As a

Re: I was wrong

On Thursday, 30 May 2013 at 18:06:03 UTC, Walter Bright wrote: about the changelog. Andrej Mitrovic has done a super awesome job with the changelog, and it is paying off big time. I am very happy to be proven wrong about it. It is so good I could not have even expected to see something like

Re: I was wrong

On Friday, 31 May 2013 at 08:38:11 UTC, Jacob Carlborg wrote: Don't know if the changelog_all is necessary. Just have links to the older versions from changelog.html. It is not necessary but is minor extra convenience for users not needing those 60+ extra links when they just want to check las

Re: 2.063 release

On Thursday, 30 May 2013 at 17:19:51 UTC, Walter Bright wrote: On 5/30/2013 9:04 AM, Russel Winder wrote: It seems that download speed is about 500b/s, so about 3 weeks to download :-( Some of the downloads have been moved to S3 (Thanks, Brad!). The download links are here: http://digitalm

Re: I was wrong

On 2013-05-30 21:44, Timothee Cour wrote: shall we have both the current changelog for all releases + individual changelogs per release changelog.html // always latest version only; people go there by default changelog_all.html //same as current changelog.html changelog_2063.html changelog_2062.

Re: A different tuple syntax

On Friday, 31 May 2013 at 07:32:42 UTC, w0rp wrote: On Friday, 31 May 2013 at 04:49:41 UTC, deadalnix wrote: On Friday, 31 May 2013 at 03:07:22 UTC, nazriel wrote: Now this: auto #(x, y) = foo(); #(int x1, string y1) = foo(); #(int, string) foo() { #(int tmp, string tmp2) = #(3,

Re: A different tuple syntax

On Friday, 31 May 2013 at 04:49:41 UTC, deadalnix wrote: On Friday, 31 May 2013 at 03:07:22 UTC, nazriel wrote: Now this: auto #(x, y) = foo(); #(int x1, string y1) = foo(); #(int, string) foo() { #(int tmp, string tmp2) = #(3, "dsa"); return #(42, "dsa"); } This

Will I try again? and also C header files.

I looked at the D programming language a few years ago and though it was good. Then I ran into trouble. The language was in a state of flux. I would write code and with the next version of D it would no longer work. The same thing was happening to people who were writing tools such as IDE's

<    1   2