Re: Biggest Issue with D - Definition and Versioning

On Sat, 14 Jan 2012 21:31:14 -0600 Andrei Alexandrescu wrote: > In the latter case: > > 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the > list. Now it's like the last 'copter outta Saigon. > > 2. We haven't identified game designers as a core market, and one > that's more

Re: Biggest Issue with D - Definition and Versioning

On Sun, 15 Jan 2012 04:31:14 +0100, Andrei Alexandrescu wrote: On 1/14/12 9:06 PM, Jonathan M Davis wrote: On Saturday, January 14, 2012 20:54:55 Michel Fortin wrote: Still, Walter perfectly has the right to decide on what he wants to work. I understand that he saw implementing SIMD as an i

Re: Biggest Issue with D - Definition and Versioning

On Sunday, January 15, 2012 10:05:34 Martin Nowak wrote: > This is a huge selling point. > float4 v1,v2,v3; > v1 = v2; > v1 = v2 + v3; > v1 = v2 - v3; > v1 = v2 * v3; > v1 = v2 / v3; I think that the main point is that it is _not_ a big selling point for the majority

Re: SIMD support...

On 15 January 2012 08:16, Sean Cavanaugh wrote: > On 1/15/2012 12:09 AM, Walter Bright wrote: > >> On 1/14/2012 9:58 PM, Sean Cavanaugh wrote: >> >>> MS has three types, __m128, __m128i and __m128d (float, int, double) >>> >>> Six if you count AVX's 256 forms. >>> >>> On 1/7/2012 6:54 PM, Peter A

Re: SIMD support...

On 15 January 2012 09:20, Sean Cavanaugh wrote: > On 1/13/2012 7:38 AM, Manu wrote: > >> On 13 January 2012 08:34, Norbert Nemec > > wrote: >> >> >> This has already been concluded some days back, the language has a quite >> of types, just like GCC. >> > > So I

Re: Biggest Issue with D - Definition and Versioning

On 15/01/12 3:31 AM, Andrei Alexandrescu wrote: 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the list. Now it's like the last 'copter outta Saigon. That's not true. SIMD intrinsics has always been on the list. I've only been in this newsgroup for a year or so, but I've defi

Re: SIMD benchmark

On 15/01/12 6:56 AM, Walter Bright wrote: I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. Anyhow, it's good enough now to play around with. Consider it alpha quality. Expect bugs - but make bug reports, as there's a serious lack of source code to test it with. You sure yo

Re: GCC depen issue on linux

On 2012-01-14 23:39, Nick Sabalausky wrote: "mta`chrono" wrote in message news:jesv45$1elt$1...@digitalmars.com... It seems like you have installed a precompiled version of dmd. Can you post eactly the source where you've downloaded it? dmd seems to require version _2.11_ of glibc. there are a

Re: Biggest Issue with D - Definition and Versioning

On 2012-01-15 06:00, Michel Fortin wrote: On 2012-01-15 03:06:22 +, Jonathan M Davis said: It seems that the problem is that while Walter can be saved effort by having someone else do that kind of work, it doesn't necessarily save him all that much effort, since he still must ultimately ta

Intrusive Makefile for d-programming-language.org

I'm not particularly well versed in Makefile ethics, but this caught me by surprise. Suppose I clone d-programming-language.org into my home directory (as I did), do some work, then later on run make clean. git clone https://.../d-programming-language.org.git cd d-programming-language.org ...

Re: Biggest Issue with D - Definition and Versioning

On Sunday, 15 January 2012 at 03:31:15 UTC, Andrei Alexandrescu wrote: On 1/14/12 9:06 PM, Jonathan M Davis wrote: On Saturday, January 14, 2012 20:54:55 Michel Fortin wrote: Still, Walter perfectly has the right to decide on what he wants to work. I understand that he saw implementing SIMD as

Re: Biggest Issue with D - Definition and Versioning

Andrei Alexandrescu: > 2. We haven't identified game designers as a core market, and one that's > more important than e.g. general purpose programmers who need the like > of working qualifiers, multithreading, and shared libraries. >From what I've seen games were one of the very few significant

Re: Intrusive Makefile for d-programming-language.org

> If I had a web dir in my home directory (not exactly uncommon), it would > have been deleted without warning. Luckily, I didn't. I now have it > cloned into a separate dir where it can do no harm. > > Is it normal for Makefiles to be so intrusive? IMO, Makefiles shouldn't > be deleting anything

Call site 'ref'

Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because it's not at all obvious that a function you're calling is taking a 'ref' parameter. This is

Re: Call site 'ref'

You are, lazy, sir, and your programming license should be revoked. By that logic we should dull all knives because somebody might get hurt. My 2c.

Re: Call site 'ref'

On 15/01/12 1:56 PM, Johnatan Frakes wrote: You are, lazy, sir, and your programming license should be revoked. By that logic we should dull all knives because somebody might get hurt. My 2c. This has nothing to do with laziness. It's an error-detection mechanism, just like many other langua

Re: Call site 'ref'

On 15-01-2012 14:56, Johnatan Frakes wrote: You are, lazy, sir, and your programming license should be revoked. By that logic we should dull all knives because somebody might get hurt. My 2c. By your logic, we should remove all compiler checks that help avoid typical mistakes. This is not ab

Re: Call site 'ref'

On 15-01-2012 15:12, Peter Alexander wrote: On 15/01/12 1:56 PM, Johnatan Frakes wrote: You are, lazy, sir, and your programming license should be revoked. By that logic we should dull all knives because somebody might get hurt. My 2c. This has nothing to do with laziness. It's an error-dete

Re: Call site 'ref'

Alex Rønne Petersen wrote: Ideally, this would not be optional, but rather *required*, but I realize that such a change would break a *lot* of code, so that's probably not a good idea. Thoughts? Good idea, but it should be optional. On by default maybe, but optional.

Re: Call site 'ref'

On 15-01-2012 15:05, F i L wrote: Alex Rønne Petersen wrote: Ideally, this would not be optional, but rather *required*, but I realize that such a change would break a *lot* of code, so that's probably not a good idea. Thoughts? Good idea, but it should be optional. On by default maybe, but o

[your code here]

import std.conv, std.traits, std.ascii; S rot13(S)(S s) if (isSomeString!S) { return rot(s, 13); } S rot(S)(S s, int key) if (isSomeString!S) { dchar[] r = new dchar[s.length]; foreach (i, dchar c; s) { if (isLower(c)) c = ((c - 'a' + key) % 26 + 'a'); el

Re: Biggest Issue with D - Definition and Versioning

"Michel Fortin" wrote in message news:jetbld$23qt$1...@digitalmars.com... > Looks good in theory, but in practice this approach hasn't worked very > well for pull request number 3. > I may have mentioned this before, but there are a couple of things that make me think pull 3 shouldn't be merge

Re: Intrusive Makefile for d-programming-language.org

On 2012-01-15 14:28, mta`chrono wrote: If I had a web dir in my home directory (not exactly uncommon), it would have been deleted without warning. Luckily, I didn't. I now have it cloned into a separate dir where it can do no harm. Is it normal for Makefiles to be so intrusive? IMO, Makefiles sh

Re: Biggest Issue with D - Definition and Versioning

On 15/01/2012 14:26, Daniel Murphy wrote: "Michel Fortin" wrote in message news:jetbld$23qt$1...@digitalmars.com... Looks good in theory, but in practice this approach hasn't worked very well for pull request number 3. I may have mentioned this before, but there are a couple of things that m

Re: Biggest Issue with D - Definition and Versioning

On 2012-01-15 14:26:45 +, "Daniel Murphy" said: I may have mentioned this before, but there are a couple of things that make me think pull 3 shouldn't be merged as is. (Even if it was made merge-ready) 1. The patch tries (and in some places, doesn't try) to match implicit conversion and te

Re: [your code here]

Jos van Uden: > still learning this stuff, feel free to correct or improve Next time I suggest you to use D.learn. This is a first draft with some changes: import std.traits, std.string, std.ascii, std.conv, std.range; // is partial application better here? dstring rot13(C)(immutable(C[]) s) p

Re: Biggest Issue with D - Definition and Versioning

On 1/15/12 5:30 AM, Peter Alexander wrote: On 15/01/12 3:31 AM, Andrei Alexandrescu wrote: 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the list. Now it's like the last 'copter outta Saigon. That's not true. SIMD intrinsics has always been on the list. I've only been in thi

Re: Call site 'ref'

On 1/15/2012 8:36 AM, Alex Rønne Petersen wrote: Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because it's not at all obvious that a function you'r

Re: Intrusive Makefile for d-programming-language.org

On 1/15/12 7:09 AM, Peter Alexander wrote: I'm not particularly well versed in Makefile ethics, but this caught me by surprise. Suppose I clone d-programming-language.org into my home directory (as I did), do some work, then later on run make clean. git clone https://.../d-programming-language.

Re: [your code here]

On 1/15/12 8:23 AM, Jos van Uden wrote: import std.conv, std.traits, std.ascii; S rot13(S)(S s) if (isSomeString!S) { return rot(s, 13); } S rot(S)(S s, int key) if (isSomeString!S) { dchar[] r = new dchar[s.length]; foreach (i, dchar c; s) { if (isLower(c)) c = ((c - 'a' + key) % 26 + 'a'); e

Re: [your code here]

Andrei Alexandrescu: > Thanks! Well, we don't have yet the javascript that rotates the > examples. Would anyone be interested to work on that? Do you want a large amount of D2 "examples"? Have you seen this page? http://rosettacode.org/wiki/Category:D Bye, bearophile

Re: Call site 'ref'

On 15/01/12 3:19 PM, dsimcha wrote: On 1/15/2012 8:36 AM, Alex Rønne Petersen wrote: Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because it's not

Re: [your code here]

On 1/15/12 9:26 AM, bearophile wrote: Andrei Alexandrescu: Thanks! Well, we don't have yet the javascript that rotates the examples. Would anyone be interested to work on that? Do you want a large amount of D2 "examples"? Have you seen this page? http://rosettacode.org/wiki/Category:D Bye, b

Re: [your code here]

On 01/15/2012 03:23 PM, Jos van Uden wrote: import std.conv, std.traits, std.ascii; S rot13(S)(S s) if (isSomeString!S) { return rot(s, 13); } S rot(S)(S s, int key) if (isSomeString!S) { dchar[] r = new dchar[s.length]; foreach (i, dchar c; s) { if (isLower(c)) c = ((c - 'a' + key) % 26 + 'a'

Re: [your code here]

On 15-1-2012 17:26, Timon Gehr wrote: On 01/15/2012 03:23 PM, Jos van Uden wrote: import std.conv, std.traits, std.ascii; S rot13(S)(S s) if (isSomeString!S) { return rot(s, 13); } S rot(S)(S s, int key) if (isSomeString!S) { dchar[] r = new dchar[s.length]; foreach (i, dchar c; s) { if (isLo

Re: SIMD benchmark

On 15 January 2012 06:56, Walter Bright wrote: > I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. > Anyhow, it's good enough now to play around with. Consider it alpha quality. > Expect bugs - but make bug reports, as there's a serious lack of source code > to test it with.

Re: Biggest Issue with D - Definition and Versioning

On 01/14/2012 10:31 PM, Andrei Alexandrescu wrote: 2. We haven't identified game designers as a core market You probably should, as C++ is the de facto standard in the games industry, and the one area where D could shine above languages like C# or Java. You might even be able to get some fundi

Re: Biggest Issue with D - Definition and Versioning

I'm interested in game development using D, so I'll post my opinion. I think the discussions here show how particularly specialized people here are. I've seen some Manu's posts and it was clear that he is a person in gamedev who thinks most development is like gamedev and can't see the bigger pict

Re: Call site 'ref'

On 15-01-2012 16:47, Peter Alexander wrote: On 15/01/12 3:19 PM, dsimcha wrote: On 1/15/2012 8:36 AM, Alex Rønne Petersen wrote: Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are j

Re: Biggest Issue with D - Definition and Versioning

On 15-01-2012 18:02, Jeff Nowakowski wrote: On 01/14/2012 10:31 PM, Andrei Alexandrescu wrote: 2. We haven't identified game designers as a core market You probably should, as C++ is the de facto standard in the games industry, and the one area where D could shine above languages like C# or J

Re: Call site 'ref'

On Sun, 15 Jan 2012 07:36:53 -0600, Alex Rønne Petersen wrote: Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because it's not at all obvious that

Re: SIMD benchmark

On 15 January 2012 16:59, Iain Buclaw wrote: > On 15 January 2012 06:56, Walter Bright wrote: >> I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. >> Anyhow, it's good enough now to play around with. Consider it alpha quality. >> Expect bugs - but make bug reports, as there's

Re: Call site 'ref'

On 15/01/12 5:57 PM, Robert Jacques wrote: On Sun, 15 Jan 2012 07:36:53 -0600, Alex Rønne Petersen Thoughts? In no particular order: 1) Adding ref to the call site is lexically similar to Hungarian notation and has all the drawbacks and advantages thereof. I know invoking Hungarian notation i

Re: Call site 'ref'

On 1/15/2012 5:36 AM, Alex Rønne Petersen wrote: Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because it's not at all obvious that a function yo

Re: SIMD support...

On 1/15/2012 3:02 AM, Manu wrote: On 15 January 2012 09:20, Sean Cavanaugh A nice vector math library for D that puts us competitive will be a nice addition to Phobos.

Re: SIMD benchmark

On 1/15/2012 3:49 AM, Peter Alexander wrote: Actually, looking at the auto-tester, I'm not alone. Just seems to be OSX though. Yeah, it's just OSX. I had the test for that platform inadvertently disabled, gak.

Re: SIMD benchmark

On 15 January 2012 20:10, Iain Buclaw wrote: > On 15 January 2012 16:59, Iain Buclaw wrote: > > On 15 January 2012 06:56, Walter Bright > wrote: > >> I get a 2 to 2.5 speedup with the vector instructions on 64 bit Linux. > >> Anyhow, it's good enough now to play around with. Consider it alpha >

Re: SIMD benchmark

On 1/15/2012 10:10 AM, Iain Buclaw wrote: Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up with -O2 and above. My oh my... Woo-hoo!

Re: Call site 'ref'

> I also know that people dislike using reference parameters in C++ due to > the lack of visibility at the call site (causing them to use pointers). Which is true for me. Every single one of my reference parameters is const ref or pointer.

Re: SIMD benchmark

Iain Buclaw: > Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up > with -O2 and above. My oh my... Please, show me the assembly code produced, with its relative D source :-) Bye, bearophile

Re: Call site 'ref'

Robert Jacques: > 1) Adding ref to the call site is lexically similar to Hungarian notation and > has all the drawbacks and advantages thereof. The presence of "ref" at the call site is meant to be enforced by the type system of the compiler. > Or more to the original point, modern IDEs alrea

Re: Call site 'ref'

Tobias Pankrath: > > I also know that people dislike using reference parameters in C++ due to > > the lack of visibility at the call site (causing them to use pointers). > > Which is true for me. Every single one of my reference parameters is const > ref or pointer. (What you do is also require

Re: Biggest Issue with D - Definition and Versioning

On 1/15/2012 6:47 AM, Robert Clipsham wrote: Might be worth adding this as a comment on the pull request! Yes, please do.

Re: SIMD benchmark

On 15 January 2012 19:01, bearophile wrote: > Iain Buclaw: > >> Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up >> with -O2 and above.  My oh my... > > Please, show me the assembly code produced, with its relative D source :-) > > Bye, > bearophile D code: import core.

[OT] Re: [your code here]

"Andrei Alexandrescu" wrote in message news:jeuqua$1gfg$3...@digitalmars.com... > > Thanks! Well, we don't have yet the javascript that rotates the examples. > Would anyone be interested to work on that? > Speaking of d-p-l.org contributions, #39 has been merged and could use to be put up on t

Re: SIMD benchmark

On 15 January 2012 19:01, bearophile wrote: > Iain Buclaw: > >> Correction, 1.5x speed up without, 20x speed up with -O1, 30x speed up >> with -O2 and above.  My oh my... > > Please, show me the assembly code produced, with its relative D source :-) > > Bye, > bearophile For those who can't read

Re: Biggest Issue with D - Definition and Versioning

"Andrei Alexandrescu" wrote in message news:jetha2$2csv$1...@digitalmars.com... > > 2. We haven't identified game designers as a core market, and one that's > more important than e.g. general purpose programmers who need the like of > working qualifiers, multithreading, and shared libraries. >

Re: Biggest Issue with D - Definition and Versioning

On 15-01-2012 21:57, Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:jetha2$2csv$1...@digitalmars.com... 2. We haven't identified game designers as a core market, and one that's more important than e.g. general purpose programmers who need the like of working qualifiers, mul

Re: Call site 'ref'

"Alex Rønne Petersen" wrote in message news:jeukpm$168v$1...@digitalmars.com... > Hi, > > I don't know how many times I've made the mistake of passing a local > variable to a function which takes a 'ref' parameter. Suddenly, local > variables/fields are just mutating out of nowhere, because it'

Re: Call site 'ref'

On 01/15/2012 02:36 PM, Alex Rønne Petersen wrote: Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because it's not at all obvious that a function you

Re: Call site 'ref'

On 15/01/12 10:10 PM, Timon Gehr wrote: Another thing that would have to be discussed: what happens to const ref parameters? It is very reasonable that someone will decide to change calling conventions from by value to by const ref or the other way round after profiling. It is very convenient tha

Re: Call site 'ref'

On 01/15/2012 11:10 PM, Timon Gehr wrote: On 01/15/2012 02:36 PM, Alex Rønne Petersen wrote: Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are just mutating out of nowhere, because

Re: Call site 'ref'

On 01/15/2012 11:41 PM, Peter Alexander wrote: On 15/01/12 10:10 PM, Timon Gehr wrote: Another thing that would have to be discussed: what happens to const ref parameters? It is very reasonable that someone will decide to change calling conventions from by value to by const ref or the other way

Re: Call site 'ref'

On 01/15/2012 10:39 PM, Nick Sabalausky wrote: "Alex Rønne Petersen" wrote in message news:jeukpm$168v$1...@digitalmars.com... Hi, I don't know how many times I've made the mistake of passing a local variable to a function which takes a 'ref' parameter. Suddenly, local variables/fields are jus

Re: Call site 'ref'

On 01/15/2012 11:36 PM, Timon Gehr wrote: On 01/15/2012 11:41 PM, Peter Alexander wrote: On 15/01/12 10:10 PM, Timon Gehr wrote: Another thing that would have to be discussed: what happens to const ref parameters? It is very reasonable that someone will decide to change calling conventions from

Re: Call site 'ref'

On 15/01/12 10:36 PM, Timon Gehr wrote: On 01/15/2012 11:41 PM, Peter Alexander wrote: On 15/01/12 10:10 PM, Timon Gehr wrote: Another thing that would have to be discussed: what happens to const ref parameters? It is very reasonable that someone will decide to change calling conventions from b

Re: Call site 'ref'

On 01/16/2012 12:39 AM, Peter Alexander wrote: On 15/01/12 10:36 PM, Timon Gehr wrote: On 01/15/2012 11:41 PM, Peter Alexander wrote: On 15/01/12 10:10 PM, Timon Gehr wrote: Another thing that would have to be discussed: what happens to const ref parameters? It is very reasonable that someone

version()

Why can't I do this: version( linux || OSX ) { something common to each } ??? This is not acceptable: version( MinGW ) { version = linuxOrMinGW; } else version( linux ) { version = linuxOrMinGW; } version( linuxOrMinGW ) { seriously...? } Surely basic logical expressions within a versio

Re: Biggest Issue with D - Definition and Versioning

On Sunday, January 15, 2012 18:42:25 Kiith-Sa wrote: > To be clear: I'm not saying that fixing the advertised features is > unimportant. In fact, the greatest problems I see in promoting D are that > we don't even have finished containers in the API - and that many features > described in TDPL don'

Re: Call site 'ref'

On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: > Well, struct literals are lvalues, at least in DMD. Yeah. I don't understand that. I've argued about it with Walter before. Apparently they are in C++ as well. I don't understand it. It makes it so that void func(ref S val) S bar(); works

Re: Call site 'ref'

On Sunday, January 15, 2012 14:36:53 Alex Rønne Petersen wrote: > Thoughts? This was discussed before, and I'm still completely against it. It _only_ has value IMHO if it's required, and even then, I don't like the idea. If it's _not_ required, then you don't know _still_ don't know whether a f

Re: version()

On Monday, January 16, 2012 01:44:56 Manu wrote: > Surely basic logical expressions within a version seem not only logical, > but also very necessary? > There must be a reason this is impossible, or else I can't believe it's not > already like that... People have requested it. Walter is against it

Re: version()

On 16 January 2012 02:08, Jonathan M Davis wrote: > On Monday, January 16, 2012 01:44:56 Manu wrote: > > Surely basic logical expressions within a version seem not only logical, > > but also very necessary? > > There must be a reason this is impossible, or else I can't believe it's > not > > alre

Re: Call site 'ref'

El 15/01/2012 20:04, Tobias Pankrath escribió: I also know that people dislike using reference parameters in C++ due to the lack of visibility at the call site (causing them to use pointers). Which is true for me. Every single one of my reference parameters is const ref or pointer. swap(ref a

Re: Call site 'ref'

On 15/01/12 11:56 PM, Jonathan M Davis wrote: On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: Well, struct literals are lvalues, at least in DMD. Yeah. I don't understand that. I've argued about it with Walter before. Apparently they are in C++ as well. I don't understand it. It makes i

Re: Biggest Issue with D - Definition and Versioning

On 1/15/12 11:42 AM, Kiith-Sa wrote: I'm interested in game development using D, so I'll post my opinion. I think the discussions here show how particularly specialized people here are. I've seen some Manu's posts and it was clear that he is a person in gamedev who thinks most development is lik

Re: Call site 'ref'

On 01/16/2012 01:30 AM, Peter Alexander wrote: On 15/01/12 11:56 PM, Jonathan M Davis wrote: On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: Well, struct literals are lvalues, at least in DMD. Yeah. I don't understand that. I've argued about it with Walter before. Apparently they are i

Re: version()

On Monday, January 16, 2012 02:16:03 Manu wrote: > > As for > > > > version(linux || OSX) > > > > you can use > > > > version(Posix) > > > > It'll include FreeBSD as well, but then again, if something is common to > > both > > linux and OSX, then it's almost certainly in FreeBSD as well. > > F

Re: Call site 'ref'

On 1/15/12 6:30 PM, Peter Alexander wrote: On 15/01/12 11:56 PM, Jonathan M Davis wrote: On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: Well, struct literals are lvalues, at least in DMD. Yeah. I don't understand that. I've argued about it with Walter before. Apparently they are in C+

Re: version()

On 01/15/2012 06:16 PM, Manu wrote: On 16 January 2012 02:08, Jonathan M Davis mailto:jmdavisp...@gmx.com>> wrote: On Monday, January 16, 2012 01:44:56 Manu wrote: > Surely basic logical expressions within a version seem not only logical, > but also very necessary? > There

Re: version()

Manu: > Any sane person would look at that and wonder > WTF... especially someone new to the language. I think this D design decision needs a FAQ entry. Bye, bearophile

Re: Call site 'ref'

On 01/16/2012 01:35 AM, Andrei Alexandrescu wrote: On 1/15/12 6:30 PM, Peter Alexander wrote: On 15/01/12 11:56 PM, Jonathan M Davis wrote: On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: Well, struct literals are lvalues, at least in DMD. Yeah. I don't understand that. I've argued ab

Re: Call site 'ref'

On 16/01/12 12:35 AM, Andrei Alexandrescu wrote: On 1/15/12 6:30 PM, Peter Alexander wrote: On 15/01/12 11:56 PM, Jonathan M Davis wrote: On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: Well, struct literals are lvalues, at least in DMD. Yeah. I don't understand that. I've argued abou

Re: version()

On 16/01/12 12:37 AM, Jonathan M Davis wrote: Yes, right now. Everything that isn't Posix may be Windows, but that won't necessarily always be true. So, when it comes to versioning, code should definitely be versioned on what it _is_ rather than what it _isn't_. But that doesn't preclude having&&

Re: Call site 'ref'

On 1/15/12 6:38 PM, Timon Gehr wrote: On 01/16/2012 01:35 AM, Andrei Alexandrescu wrote: On 1/15/12 6:30 PM, Peter Alexander wrote: On 15/01/12 11:56 PM, Jonathan M Davis wrote: On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: Well, struct literals are lvalues, at least in DMD. Yeah.

Re: Call site 'ref'

On Sun, 15 Jan 2012 12:27:46 -0600, Peter Alexander wrote: On 15/01/12 5:57 PM, Robert Jacques wrote: On Sun, 15 Jan 2012 07:36:53 -0600, Alex Rønne Petersen Thoughts? In no particular order: 1) Adding ref to the call site is lexically similar to Hungarian notation and has all the drawback

Re: version()

On Monday, January 16, 2012 01:14:32 Peter Alexander wrote: > On 16/01/12 12:37 AM, Jonathan M Davis wrote: > > Yes, right now. Everything that isn't Posix may be Windows, but that > > won't necessarily always be true. So, when it comes to versioning, code > > should definitely be versioned on what

Re: Call site 'ref'

On 01/16/2012 02:00 AM, Andrei Alexandrescu wrote: On 1/15/12 6:38 PM, Timon Gehr wrote: On 01/16/2012 01:35 AM, Andrei Alexandrescu wrote: On 1/15/12 6:30 PM, Peter Alexander wrote: On 15/01/12 11:56 PM, Jonathan M Davis wrote: On Monday, January 16, 2012 00:41:14 Timon Gehr wrote: Well, st

Re: Call site 'ref'

2012/1/15 Alex Rønne Petersen : > Hi, > > I don't know how many times I've made the mistake of passing a local > variable to a function which takes a 'ref' parameter. Suddenly, local > variables/fields are just mutating out of nowhere, because it's not at all > obvious that a function you're callin

Re: No parenthesis for assert?

On 14/01/2012 15:32, Alex Rønne Petersen wrote: As such, it would be a case of explicitly disallowing assert ( CommaExpression ) in the grammar. Correction: because of the way the grammar works, it would be a case of explicitly disallowing assert ( AssignExpression , CommaExpression ) Stew

Re: SIMD support...

On 1/15/2012 1:42 PM, Walter Bright wrote: A nice vector math library for D that puts us competitive will be a nice addition to Phobos. The gl3n library might be something good to build on: https://bitbucket.org/dav1d/gl3n It looks to be a continuation of the OMG library used by Deadlock, and

Re: SIMD support...

On 1/15/2012 6:54 PM, JoeCoder wrote: On 1/15/2012 1:42 PM, Walter Bright wrote: A nice vector math library for D that puts us competitive will be a nice addition to Phobos. The gl3n library might be something good to build on: https://bitbucket.org/dav1d/gl3n It looks to be a continuation o

__declspec(dllexport)

D2 is Great, I've got D based numeric array DLLs extending Python Numpy.. My Question is: What is the D2 language's equivalent for __declspec(dllexport).. Can one export variables as well as functions from a DLL's symbol table, while programing in D2 with dmd? -Peter

Re: __declspec(dllexport)

On 01/16/2012 04:26 AM, Peter Lindener wrote: D2 is Great, I've got D based numeric array DLLs extending Python Numpy.. My Question is: What is the D2 language's equivalent for __declspec(dllexport).. Afaik it is simply the 'export' storage class. Can one export variables as well as functions

Re: Biggest Issue with D - Definition and Versioning

"Alex Rønne Petersen" wrote in message news:jevgk4$2nq3$1...@digitalmars.com... > On 15-01-2012 21:57, Nick Sabalausky wrote: >> "Andrei Alexandrescu" wrote in message >> news:jetha2$2csv$1...@digitalmars.com... >>> >>> 2. We haven't identified game designers as a core market, and one that's >>>

Re: Biggest Issue with D - Definition and Versioning

"Nick Sabalausky" wrote in message news:jf0au6$12jv$1...@digitalmars.com... > "Alex Rønne Petersen" wrote in message > news:jevgk4$2nq3$1...@digitalmars.com... >> . >> And yet, D's situation on Windows, the main gaming platform, is less than >> ideal. If we're really going to cater to game dev

Re: version()

On 16 January 2012 02:37, Jonathan M Davis wrote: > On Monday, January 16, 2012 02:16:03 Manu wrote: > > > As for > > > > > > version(linux || OSX) > > > > > > you can use > > > > > > version(Posix) > > > > > > It'll include FreeBSD as well, but then again, if something is common > to > > > both

Re: version()

On 16 January 2012 02:35, Zachary Lund wrote: > On 01/15/2012 06:16 PM, Manu wrote: > >> On 16 January 2012 02:08, Jonathan M Davis > > wrote: >> >>On Monday, January 16, 2012 01:44:56 Manu wrote: >> > Surely basic logical expressions within a version seem not

Re: version()

On 1/16/2012 8:44 AM, Manu wrote: Why can't I do this: version( linux || OSX ) { something common to each } ??? This is not acceptable: version( MinGW ) { version = linuxOrMinGW; } else version( linux ) { version = linuxOrMinGW; } version( linuxOrMinGW ) { seriously...? } Surely bas

Re: version()

On 2012-01-16 00:44, Manu wrote: Why can't I do this: version( linux || OSX ) { something common to each } ??? This is not acceptable: version( MinGW ) { version = linuxOrMinGW; } else version( linux ) { version = linuxOrMinGW; } version( linuxOrMinGW ) { seriously...? } Surely basi

  1   2   >