date:20110704


On 7/4/2011 5:38 PM, Mehrdad wrote:

Actually, there is **NO** performance issue -- at least not in C#. In fact, if
you run this program (with or without optimizations), you will see that they're
literally the same almost all the time:


It's a bit extraordinary that there is no cost in executing extra instructions.

I've seen many programmers (including experts) led down a primrose path on 
optimizations because they thought A was happening when actually B was. It pays 
to check the assembler output and see what's happening.


In your benchmark case, it is possible that the optimizer discovers that i is in 
the range 0..COUNT, and that i*i can therefore never overflow, and then the 
overflow check is eliminated.


Or it is possible that the compiler realizes that globalVar, despite being 
global, is never read from, and hence the assignments to it are dead, and hence 
the i*i is never computed at all.


Or that the loop is unrolled 10 times, and the overflow check is only done once 
per 10 iterations, burying its cost.


In other words perhaps it's a special case optimization happening, and is not 
indicative at all of the actual cost of overflow checks in the usual case, which 
cannot be optimized away.

Re: d-programming-language.org


On 7/4/11 7:38 PM, Mehrdad wrote:

Since I didn't see this being mentioned anywhere, I thought I'd mention
it...

On 7/4/2011 1:58 PM, Andrei Alexandrescu wrote:

On 7/4/11 2:48 PM, bearophile wrote:

In this case you wrap the code in something that allows it to
overflow without errors, like:

unsafe(overflows) { // code here }


This approach has a number of issues. First, addressing transitivity is
difficult. If the code in such a scope calls a function, either every
function has two versions, or chooses one way to go about it. Each
choice has obvious drawbacks.


C# chooses to limit the scope to the current function, and it works
pretty well. The use is to modify the behavior of the *operators*, and
hence, there's no transitivity issue because that's just not what it's
used for.


Well that's a choice with its inherent tradeoffs.


Second, programmers are notoriously bad at choosing which code is
affecting bottom line performance, yet this feature explicitly puts the
burden on the coder. So code will be littered with amends, yet still be
overall slower. This feature has very poor scalability.


Actually, there is **NO** performance issue -- at least not in C#. In
fact, if you run this program (with or without optimizations), you will
see that they're literally the same almost all the time:

using System;

static class Program
{
static long globalVar = 0; //Make it static so it doesn't get optimized
static void Main()
{
const long COUNT = 1;
for (;;)
{
var start = Environment.TickCount;
for (long i = 0; i < COUNT; i++)
checked { globalVar = i * i; }
System.Console.WriteLine("Checked: {0}", Environment.TickCount - start);

start = Environment.TickCount;
for (long i = 0; i < COUNT; i++)
unchecked { globalVar = i * i; }
System.Console.WriteLine("Unchecked: {0}", Environment.TickCount - start);
}
}
}

There is literally no performance issue. Ever.


Isn't it a bit of a stretch to derive a definitive conclusion from one 
small test?



Andrei

Re: D Programming Language Specification ebook


On 7/4/11 6:53 PM, Torarin wrote:

2011/7/5 Andrei Alexandrescu:


It's "whom" :o).

Andrei



Are you sure? The "people" in "people ... are complete idiots" are the
subjects of the sentence, so surely the subjective case of who is
appropriate?

Torarin


Yes, "whom" was wrong there, but that was the punchline: someone who is 
at the same time pretentious enough and dumb enough to say "whom" when 
"who" is actually correct, is the same kin as someone who equates price 
with quality.


I know, explained jokes suck...


Andrei

Re: d-programming-language.org

2011-07-04 Thread Benjamin Lindley


On 7/4/2011 7:38 PM, Mehrdad wrote:

Actually, there is **NO** performance issue -- at least not in C#. In
fact, if you run this program (with or without optimizations), you will
see that they're literally the same almost all the time:

using System;

static class Program
{
static long globalVar = 0; //Make it static so it doesn't get optimized
static void Main()
{
const long COUNT = 1;
for (;;)
{
var start = Environment.TickCount;
for (long i = 0; i < COUNT; i++)
checked { globalVar = i * i; }
System.Console.WriteLine("Checked: {0}", Environment.TickCount - start);

start = Environment.TickCount;
for (long i = 0; i < COUNT; i++)
unchecked { globalVar = i * i; }
System.Console.WriteLine("Unchecked: {0}", Environment.TickCount - start);
}
}
}

There is literally no performance issue. Ever.


Just my 2c


I ran your program, and my results are different than yours.

Checked:   1497
Unchecked: 531
Checked:   1138
Unchecked: 453
Checked:   1092
Unchecked: 468
Checked:   1092
Unchecked: 452
Checked:   1077
Unchecked: 452
Checked:   1108
Unchecked: 452
Checked:   1186
Unchecked: 452
Checked:   1092
Unchecked: 437
Checked:   1092
Unchecked: 452
Checked:   1092
Unchecked: 453
Checked:   1138
Unchecked: 437

Re: d-programming-language.org

2011-07-04 Thread Mehrdad

Since I didn't see this being mentioned anywhere, I thought I'd mention 
it...


On 7/4/2011 1:58 PM, Andrei Alexandrescu wrote:

On 7/4/11 2:48 PM, bearophile wrote:

In this case you wrap the code in something that allows it to
overflow without errors, like:

unsafe(overflows) { // code here }


This approach has a number of issues. First, addressing transitivity is
difficult. If the code in such a scope calls a function, either every
function has two versions, or chooses one way to go about it. Each
choice has obvious drawbacks.


C# chooses to limit the scope to the current function, and it works 
pretty well. The use is to modify the behavior of the *operators*, and 
hence, there's no transitivity issue because that's just not what it's 
used for.



Second, programmers are notoriously bad at choosing which code is
affecting bottom line performance, yet this feature explicitly puts the
burden on the coder. So code will be littered with amends, yet still be
overall slower. This feature has very poor scalability.


Actually, there is **NO** performance issue -- at least not in C#. In 
fact, if you run this program (with or without optimizations), you will 
see that they're literally the same almost all the time:


using System;

static class Program
{
static long globalVar = 0; //Make it static so it doesn't get 
optimized

static void Main()
{
const long COUNT = 1;
for (;;)
{
var start = Environment.TickCount;
for (long i = 0; i < COUNT; i++)
checked { globalVar = i * i; }
System.Console.WriteLine("Checked:   {0}", 
Environment.TickCount - start);


start = Environment.TickCount;
for (long i = 0; i < COUNT; i++)
unchecked { globalVar = i * i; }
System.Console.WriteLine("Unchecked: {0}", 
Environment.TickCount - start);

}
}
}

There is literally no performance issue. Ever.


Just my 2c

Re: D Programming Language Specification ebook

2011-07-04 Thread Jonathan M Davis

On 2011-07-04 16:53, Torarin wrote:
> 2011/7/5 Andrei Alexandrescu :
> > It's "whom" :o).
> > 
> > Andrei
> 
> Are you sure? The "people" in "people ... are complete idiots" are the
> subjects of the sentence, so surely the subjective case of who is
> appropriate?

I'm pretty sure that who is the correct choice here for pretty much the reason 
that you're giving, but it's the sort of thing that could get pretty 
argumentative, so I didn't say anything. Whom really isn't used much these 
days (though far more than thou or thy and their ilk), so it's more or less 
dying out of the language, though plenty of the more literary folks still use 
it. Personally, I think that life would be simpler without it, but it's not 
completely gone yet.

- Jonathan M Davis

Re: D Programming Language Specification ebook

2011-07-04 Thread Daniel Gibson

Am 05.07.2011 01:18, schrieb Walter Bright:
> On 7/3/2011 7:11 PM, Walter Bright wrote:
>> What do you all think? $0? $4.99? $9.99?
> 
> Ok, you all made a good case. It'll be $0.

Great! :-)
(Now I only need a Kindle.)

Cheers,
- Daniel

Re: D Programming Language Specification ebook

2011-07-04 Thread Torarin

2011/7/5 Andrei Alexandrescu :

> It's "whom" :o).
>
> Andrei
>

Are you sure? The "people" in "people ... are complete idiots" are the
subjects of the sentence, so surely the subjective case of who is
appropriate?

Torarin

Re: D Programming Language Specification ebook

2011-07-04 Thread Andrej Mitrovic

On 7/5/11, Nick Sabalausky  wrote:
> "Whom" is about as relevant to modern day as "Thou".

Thou're such a rebel!

Re: D Programming Language Specification ebook

"Andrei Alexandrescu"  wrote in message 
news:iuteg8$24qq$2...@digitalmars.com...
> On 7/4/11 5:08 PM, Nick Sabalausky wrote:
>> "Nick Sabalausky"  wrote in message
>> news:iutdsf$23qq$1...@digitalmars.com...
>>> "Walter Bright"  wrote in message
>>> news:iur7pc$1aks$1...@digitalmars.com...

 The difficulty is that if I put the ebook up on Amazon for free, people
 tend to equate free with "crap". It needs to have a price on it to be
 taken seriously.

>>>
>>> To be perfectly frank about it, people equate free with "crap" and
>>> expensive with "quality" are complete idiots.
>>>
>>
>> ...people *who* equate...
>
> It's "whom" :o).
>

"Whom" is about as relevant to modern day as "Thou".

Re: D Programming Language Specification ebook


On 7/3/2011 7:11 PM, Walter Bright wrote:

What do you all think? $0? $4.99? $9.99?


Ok, you all made a good case. It'll be $0.

Re: D Programming Language Specification ebook

2011-07-04 Thread Lutger Blijdestijn

Walter Bright wrote:

> On 7/4/2011 1:50 AM, Johann MacDonagh wrote:
>> On 7/3/2011 10:11 PM, Walter Bright wrote:
>>> What do you all think? $0? $4.99? $9.99?
>>
>> What about skipping Amazon and putting it up on
>> d-programming-language.org and ask for donations? I think Paypal will
>> handle the processing for you for free if you show you're not doing it
>> for profit.
> 
> People at the airport press a "free gift" on me, and then harangue me for
> a donation. I think that's the wrong image for D. People shouldn't be made
> to feel guilty about using D and not making a donation. I know it would
> turn me off, at least.

You can do it in a tasteful manner, without playing the guilt card. A price-
pot for competitions sounds like a good idea. Think of it this way: you 
enable people to contribute to D with money instead of time and expertise, 
something that is not that easy to do right now.

Re: D Programming Language Specification ebook

2011-07-04 Thread Lutger Blijdestijn

Walter Bright wrote:

> On 7/4/2011 3:40 AM, Jonathan M Davis wrote:
>> On 2011-07-04 03:24, bearophile wrote:
>>> Maybe older people equate free with "bad", but newer generations are
>>> used to find good content for free on Internet. Is D designed for older
>>> people, people used to C and C++, that hate JavaScript?
>>
>> There's a difference between free on the internet and a free book.
> 
> Exactly. It may not make rational sense, but it's true.
> 
> Free books are regarded today like free software was 20 years ago - it
> must be crap.

This does not hold for technical documentation. For TDPL yes, but not for a 
programming language specification.

This view is also losing ground for programming books. There are a quite a 
few high quality books distributed online for free, even with a paper 
publishing deal.

Re: d-programming-language.org

On 7/4/11 4:40 PM, bearophile wrote:

Andrei:

unsafe(overflows) { // code here }

This approach has a number of issues.

This approach is the one used by Delphi, Ada and C# (C# has a way to
specify even inside a single expression), so somehow it's doable.

I didn't say it wasn't doable. There, you're _quoting_ my answer: "This
approach has a number of issues."

Second, programmers are notoriously bad at choosing which code is
affecting bottom line performance, yet this feature explicitly puts
the burden on the coder. So code will be littered with amends, yet
still be overall slower. This feature has very poor scalability.<

You are looking at it from the wrong point of view.

There we go with "wrong" again.

The
overflow-safety of the code is not about performance, it's about
safety, that is about the level of safety you accept in a part of the
code.

Isn't it about the way you define safety, too?

It's about trust. If you can't accept (trust) a piece of code
to be overflow-unsafe, then you can't accept it, regardless the
amount of performance you desire.

This makes no sense. How about trusting or not a piece of code that has
possible bugs in it? That's unverifiable and unfalsifiable. That's why
the notion of "memory safety" carries weight: no matter what it does, a
memory-safe module cannot compromise the integrity of the type system.
That _is_ about trust, not integral overflow.

Of course they're not the same thing. Commonalities and
differences.

I meant that safety is not the same thing as shifting the definition
of a range. Overflow tests are not going to produce isomorphic code.

And I meant that either choice could go either way, that reasonable
people may disagree about what the choice should be, and that D will not
adopt either in the foreseeable future.

Well they also are a solid way to slow down all code.

The slowdown doesn't touch floating point numbers, some Phobos
libraries that contain trusted code, memory accesses, disk and net
accesses, it doesn't influence GUI code a lot, and in practice it's
usually acceptable to me, especially while I am developing/debugging
code.

I think you are underestimating the impact of the change. Enumerating
parts that won't be affected doesn't make the affected parts less frequent.

You are using a different version of safety than D does. D defines
very precisely safety as memory safety. Your definition is larger,
less precise, and more ad-hoc.<

D has @safe that is about memory safety. But in D there is more than
just @safe, the D Zen is about the whole D language, and in D there
are many features that help to make it safer beyond memory safety.

I'm sure you know more about the D Zen than most people, but it's not
impossible that automatic overflow checking is not a part of it.

Probably one good thing to get past is the attitude that in such a
discussion the other is "wrong".<

In a recent answer I have tried to explain why you can't implement
compile-time overflows in library code:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950

Here I am right or wrong, it's not a matter of POV.

I'm afraid it is, as your argument is rife with just debatable
statements, and is generally surprising weak compared with the zeal with
with you're quoting it. Perhaps I fail to get the gist of your
statements, so allow me:

"There are routines for run-time overflow tests in C and C++, but I am
not seeing them used." -> subjective. It all says you're frequenting
other circles than other people.

"While in Delphi I use overflow tests all the time and I see code
written by other people that have runtime overflow tests switched on."
-> subjective, relates what you do and see.

"I think that to catch integral overflow bugs in programs you can't just
add a SafeInt struct, you need a compiler-wide switch. Otherwise most
people will not use it." -> subjective and unsubstantiated. Also, if
people don't use SafeInts that frequently may actually be because it's
not a problem at the top of their list. I mean how can you draw that
conclusion from that hypothesis?

"Array bound tests are able to catch bugs in normal D code written by
everybody because you don't need to use a SafeArray instead of the built
in arrays and because array bound tests are active on default, you need
a switch to disable them. A bit more syntax is needed to disable tests
locally, where needed." -> array bounds checking is a _vital_ feature
for safe code, not an option.

I don't see how all of this makes you feel you're in possession of a
bulletproof case, and the remaining issue is to make sure the others
understand and internalize it.

I have also explained that taking an arbitrary D code written by you
and replacing all instances of int and uint with safeInt and safeUint
is not going to happen. It's like array bounds in D code. If you need
to add a safeArray type to spot all array bound overflows, then

Re: D Programming Language Specification ebook


On 7/5/11 12:18 AM, Andrei Alexandrescu wrote:

On 7/4/11 5:08 PM, Nick Sabalausky wrote:

...people *who* equate...


It's "whom" :o).

Andrei


This might be for you: 
https://chrome.google.com/webstore/detail/ialgepocjcijbnlliojljnijmeciibha 
;)


David

Re: D Programming Language Specification ebook


On 7/4/11 5:08 PM, Nick Sabalausky wrote:

"Nick Sabalausky"  wrote in message
news:iutdsf$23qq$1...@digitalmars.com...

"Walter Bright"  wrote in message
news:iur7pc$1aks$1...@digitalmars.com...


The difficulty is that if I put the ebook up on Amazon for free, people
tend to equate free with "crap". It needs to have a price on it to be
taken seriously.



To be perfectly frank about it, people equate free with "crap" and
expensive with "quality" are complete idiots.



...people *who* equate...


It's "whom" :o).

Andrei

Re: D Programming Language Specification ebook

"Walter Bright"  wrote in message 
news:iur7pc$1aks$1...@digitalmars.com...
>
> The difficulty is that if I put the ebook up on Amazon for free, people 
> tend to equate free with "crap". It needs to have a price on it to be 
> taken seriously.
>

To be perfectly frank about it, people equate free with "crap" and expensive 
with "quality" are complete idiots.

Re: D Programming Language Specification ebook

"Nick Sabalausky"  wrote in message 
news:iutdsf$23qq$1...@digitalmars.com...
> "Walter Bright"  wrote in message 
> news:iur7pc$1aks$1...@digitalmars.com...
>>
>> The difficulty is that if I put the ebook up on Amazon for free, people 
>> tend to equate free with "crap". It needs to have a price on it to be 
>> taken seriously.
>>
>
> To be perfectly frank about it, people equate free with "crap" and 
> expensive with "quality" are complete idiots.
>

...people *who* equate...

Re: D Programming Language Specification ebook

"Walter Bright"  wrote in message 
news:ius2q2$2qan$1...@digitalmars.com...
> On 7/4/2011 1:50 AM, Johann MacDonagh wrote:
>> On 7/3/2011 10:11 PM, Walter Bright wrote:
>>> What do you all think? $0? $4.99? $9.99?
>>
>> What about skipping Amazon and putting it up on 
>> d-programming-language.org and
>> ask for donations? I think Paypal will handle the processing for you for 
>> free if
>> you show you're not doing it for profit.
>
> People at the airport press a "free gift" on me, and then harangue me for 
> a donation. I think that's the wrong image for D. People shouldn't be made 
> to feel guilty about using D and not making a donation. I know it would 
> turn me off, at least.
>

I really don't think that's remotely similar.

Re: D Programming Language Specification ebook

2011-07-04 Thread Daniel Gibson

Am 04.07.2011 23:36, schrieb Walter Bright:
> On 7/4/2011 12:47 PM, Steven Schveighoffer wrote:
>> Free books does not mean free eBooks. A free book takes money to
>> create every
>> copy, so it can be assumed that if it's free, they are making their
>> money some
>> other way (i.e. they are selling you something indirectly). But a free
>> eBook
>> does not require money per copy to produce, so its quality cannot be
>> judged
>> based on the price (either way, check out alphascript publishing).
> 
> Cannot be? Sure. But it is. There were some recent articles about how
> Amazon is being flooded with junk ebooks, and that a lot of people seem
> to be filtering them based on price.
> 

And then there are these idiots selling Wikipedia articles printed on
demand quite expensively, so price is a rather bad criteria.
(See http://en.wikipedia.org/wiki/Alphascript and
http://thanetonline.blogspot.com/2011/01/great-internet-bookselling-rip-off.html
)

I wouldn't be surprised if similar (expensive) scams exist for the
kindle as well.

Cheers,
- Daniel

Re: Expected behavior?

I am not sure if this is actually a »known« issue as in »it's on 
Bugzilla«, but it also happens with unittest blocks. I was just about to 
start tracking this issue down in a big pile of CTFE-heavy code 
(https://github.com/klickverbot/thrift/blob/d-gsoc/lib/d/src/thrift/codegen.d#L416) 
– thanks for the post. ;)


David


On 7/4/11 11:32 PM, jdrewsen wrote:

I was just about to send the curl wrapper I've been working on for RFC
and did a git pull from upstream to be in sync. After that I got a new
error that may be a dmd bug.

The following is some minimal code that triggers the error.


private mixin template A() {
void foo() {}
}

void bar() {
static struct C {
mixin A!();
};
}


testd.d(6): Error: struct testd.bar.C no size yet for forward reference
testd.d(7): Error: mixin testd.bar.C.A!() error instantiating


If I move the struct C out of the function body it compiles ok. Note
that this did actually work before I did a pull from upstream.

Is this a known issue?

/Jonas

Re: d-programming-language.org


On 7/4/2011 12:48 PM, bearophile wrote:

In this case you wrap the code in something that allows it to overflow without 
errors, like:

unsafe(overflows) {
 // code here
}


Regardless of the merits of doing overflow checks, this is the completely wrong 
way to go about it.


This must be a property of the type, not of its usage.

It gets semantically pretty wacky when you have function calls for "code here".

Re: D Programming Language Specification ebook


On 7/4/2011 12:47 PM, Steven Schveighoffer wrote:

Free books does not mean free eBooks. A free book takes money to create every
copy, so it can be assumed that if it's free, they are making their money some
other way (i.e. they are selling you something indirectly). But a free eBook
does not require money per copy to produce, so its quality cannot be judged
based on the price (either way, check out alphascript publishing).


Cannot be? Sure. But it is. There were some recent articles about how Amazon is 
being flooded with junk ebooks, and that a lot of people seem to be filtering 
them based on price.




How about this, if you charge any amount of money more than 0, I guarantee you
will have less than 10% of the downloads than if you gave it away for free. Plus
you will alienate people who think they bought an actual D book (or worse, think
they are getting a deal on Andrei's book) and feel like chumps. That should be
great for D's image :P


It's a fair point.

Re: d-programming-language.org

Andrei:

> > unsafe(overflows) { // code here }

> This approach has a number of issues.

This approach is the one used by Delphi, Ada and C# (C# has a way to specify 
even inside a single expression), so somehow it's doable.


>First, addressing transitivity is difficult. If the code in such a scope calls 
>a function, either every function has two versions, or chooses one way to go 
>about it. Each choice has obvious drawbacks.<

I think in C# if you call a function from an overflow-safe zone, the code of 
the function has to be overflow-safe. I think the overflow-unsafe code is 
allowed to call overflow-safe code, so you don't need both functions.


>Second, programmers are notoriously bad at choosing which code is affecting 
>bottom line performance, yet this feature explicitly puts the burden on the 
>coder. So code will be littered with amends, yet still be overall slower. This 
>feature has very poor scalability.<

You are looking at it from the wrong point of view. The overflow-safety of the 
code is not about performance, it's about safety, that is about the level of 
safety you accept in a part of the code. It's about trust. If you can't accept 
(trust) a piece of code to be overflow-unsafe, then you can't accept it, 
regardless the amount of performance you desire. The global switch is about 
performance, and debugging, but when you annotate a part of the code with 
unsafe(overflows) {} you are stating you accept a lower level of safety for 
this part of the code (or maybe in this part of the code you are just porting 
code that uses the modular nature of unsigned numbers).


> Of course they're not the same thing. Commonalities and differences.

I meant that safety is not the same thing as shifting the definition of a 
range. Overflow tests are not going to produce isomorphic code.


> Well they also are a solid way to slow down all code.

The slowdown doesn't touch floating point numbers, some Phobos libraries that 
contain trusted code, memory accesses, disk and net accesses, it doesn't 
influence GUI code a lot, and in practice it's usually acceptable to me, 
especially while I am developing/debugging code.


>You are using a different version of safety than D does. D defines very 
>precisely safety as memory safety. Your definition is larger, less precise, 
>and more ad-hoc.<

D has @safe that is about memory safety. But in D there is more than just 
@safe, the D Zen is about the whole D language, and in D there are many 
features that help to make it safer beyond memory safety.


>Probably one good thing to get past is the attitude that in such a discussion 
>the other is "wrong".<

In a recent answer I have tried to explain why you can't implement compile-time 
overflows in library code:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950

Here I am right or wrong, it's not a matter of POV.

I have also explained that taking an arbitrary D code written by you and 
replacing all instances of int and uint with safeInt and safeUint is not going 
to happen. It's like array bounds in D code. If you need to add a safeArray 
type to spot all array bound overflows, then it's a lost cause, people are not 
going to do it (well, the case with a safeArray is better, because I am using a 
safe array in C++).


>These are simple matters of which understanding does not require any amount of 
>special talent or competence.<

Right, but several people don't have experience with using languages with 
integral overflows, so while their intelligence is plenty to understand what 
those tests do, they don't have the experience about the bugs they avoid and 
the slowdown they cause in practice in tens of practical situations. Some 
ratical experience about a feature is quite important when you want to judge 
it, I have seen it many times, with dynamic typing, good tuples, array bound 
tests, pure functions, and so on, so I suspect the same happens with integral 
overflows.


>So the first step is to understand that some may actually value a different 
>choice with different consequences than yours because they find the costs 
>unacceptable.<

I am here to explain the base of my values :-) I have tried to use rational 
arguments where possible.


>As someone who makes numerous posts and bug reports regarding speed of D code, 
>you should definitely have more appreciation for that view.<

I'm not a one trick pony, I am a bit more flexible than you think :-) In this 
case I think that fast but wrong/buggy programs are useless. Correctness comes 
first, speed second. I think D design goals agree with this view of mine :-)

Bye,
bearophile

Expected behavior?

2011-07-04 Thread jdrewsen

I was just about to send the curl wrapper I've been working on for RFC 
and did a git pull from upstream to be in sync. After that I got a new 
error that may be a dmd bug.


The following is some minimal code that triggers the error.


private mixin template A() {
void foo() {}
}

void bar() {
static struct C {
mixin A!();
};
}


testd.d(6): Error: struct testd.bar.C no size yet for forward reference
testd.d(7): Error: mixin testd.bar.C.A!() error instantiating


If I move the struct C out of the function body it compiles ok. Note 
that this did actually work before I did a pull from upstream.


Is this a known issue?

/Jonas

Re: d-programming-language.org

Steven Schveighoffer:

> Or, use a separate type which throws the errors if you wish.

I have recently explained why this is not good enough, or even currently 
impossible:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950


> I don't want  
> runtime errors thrown in code that I didn't intend to throw.  most of the  
> time, overflows will not occur, so I don't want to go through all my code  
> and have to throw these decorations up where I know it's safe.

The idea is to add two switches to DMD that activate the integral overflows 
(one for signed and one for signed and unsigned). If you compile your code 
without those, the runtime tests will not happen.


> Besides, D is a systems language, and has no business doing checks
> on every integer instruction.

This argument doesn't hold, Delphi and Ada too are system languages.


> Yes non-relase mode is slower, but we are probably talking  
> about a very significant slowdown here.  A lot of integer math happens in D.

Have you done benchmarks or are you refusing something just on a gut feeling? I 
have done benchmarks of the overflow tests in C# and Delphi and the slowdown we 
are seeing is not significantly worse than the slowdown caused by array bound 
tests. And release mode is probably going to be independent from the overflows 
switches. So you are allowed to compile in non-release mode but without 
overflow tests.


> I think a much more effective fix for the language would be to make slice  
> length a signed type.  Then you simply eliminate 99% of integer overflows  
> (it's very rare that a signed integer overflows, but not so unlikely that  
> an unsigned one does).

My bug report on this was recently closed by Andrei. I don't mind unsigned 
fixnums if their bounds are enforced.


> At this point, any change to the semantics of the builtin types will be  
> extremely disruptive.  We should focus our efforts elsewhere.

This thing is more than named arguments or syntax sugar to unpack tuples :-)

Bye,
bearophile

Re: d-programming-language.org


On 7/4/11 2:48 PM, bearophile wrote:

Steven Schveighoffer:


To the point -- lots of existing D and C code uses the properties
of integer overflow.  If integer overflow is assumed to be an
error, then that code is broken, even though the code *expects*
overflow to occur, and in fact might *depend* on it occurring.


In this case you wrap the code in something that allows it to
overflow without errors, like:

unsafe(overflows) { // code here }


This approach has a number of issues. First, addressing transitivity is
difficult. If the code in such a scope calls a function, either every
function has two versions, or chooses one way to go about it. Each
choice has obvious drawbacks.

Second, programmers are notoriously bad at choosing which code is
affecting bottom line performance, yet this feature explicitly puts the
burden on the coder. So code will be littered with amends, yet still be
overall slower. This feature has very poor scalability.




Andrei:


This and others (zero- vs. one-based indexing, closed vs. open
intervals etc.) are issues with well-understood tradeoffs that
could go either way.<


Integral overflows are not the same thing as indexing and intervals.


Of course they're not the same thing. Commonalities and differences.


Such last two are equal ways to write the same thing, while overflows
are a way to spot a class of bugs in code.


Well they also are a solid way to slow down all code.


Making a choice in such matters becomes part of a language's
ethos.<


Right, and I think D Zen is pro-safety.


You are using a different version of safety than D does. D defines very 
precisely safety as memory safety. Your definition is larger, less 
precise, and more ad-hoc.



After a while it becomes clear that rehashing such matters without
qualitatively new arguments is futile.<


I have answered because you have said wrong things. You have
implicitly said that good overflow tests are doable with library
code, and I have explained why you are wrong. This isn't futile.


Probably one good thing to get past is the attitude that in such a 
discussion the other is "wrong". These are simple matters of which 
understanding does not require any amount of special talent or 
competence. So the first step is to understand that some may actually 
value a different choice with different consequences than yours because 
they find the costs unacceptable. As someone who makes numerous posts 
and bug reports regarding speed of D code, you should definitely have 
more appreciation for that view.



Andrei

Re: d-programming-language.org

2011-07-04 Thread Timon Gehr

eles wrote:
>> Yes non-relase mode is slower, but we are probably talking
>> about a very significant slowdown here.  A lot of integer math
>> happens in
>> D.
>
> What about testing only for user selected variables/types?
[snip.]

How is Uncircular!uint not up to that particular task? Arguably, it can be less
efficient than a built-in solution, but why do you need that efficiency for 
debug
builds?

Cheers,
-Timon

Re: D Programming Language Specification ebook

2011-07-04 Thread Jonathan M Davis

On 2011-07-04 08:32, Andrei Alexandrescu wrote:
> On 7/4/11 5:58 AM, Steven Schveighoffer wrote:
> > My biggest concern with publishing a non-free book based on the web site
> > is that the *website changes with every release*!
> > 
> > Who wants to pay $5 every time the compiler is released just so you can
> > have an ebook-style copy of the web data?
> 
> I think that's a good argument.

Yes. Personally, I would be very surprised to see a copy of online 
documentation being sold as an e-book for money. And if you had to pay for it 
again every time that there was an update, it would be that much worse. In the 
case of Pro Git, it seems to me that it's not so much a case of online 
documentation being sold for money but a book being given away for free 
online. And if you'll notice, you can buy a paperback copy of Pro Git, so I 
expect that the thinking that went into selling Pro Git for money was very 
different. It probably ended up with a kindle edition to go with the paperback 
book rather than to extend what was posted online. And most importantly, Pro 
Git is an actual book which was written by one person and probably took a fair 
bit of time and effort to write. It's not online documentation. It's an actual 
book. Really, I think that it's a case of a book being given away for free 
online instead of materials from online being put into a book. I don't think 
that it's comparable to D's online documentation.

I do think that if you have an actual book, it looks bad if it's sold for free 
(e.g. a free kindle copy of TDPL would probably not be a good idea), but I 
also agree with Steven that it looks bad to sell online documentation. I 
really think that it should be free. If someone wants a quality book that they 
have to pay for, then they can buy TDPL. But selling online documentation 
looks just plain bad IMHO, and if we make it clear that the e-book is a copy 
of the online docs, then I don't think that the free factor will cause much in 
the way of problems. If anything, it's the fact that it's online documentation 
instead of an actual book which would cause problems.

- Jonathan M Davis

Re: d-programming-language.org

> Yes non-relase mode is slower, but we are probably talking
> about a very significant slowdown here.  A lot of integer math
happens in
> D.

What about testing only for user selected variables/types?

> I think a much more effective fix for the language would be to make
slice
> length a signed type.  Then you simply eliminate 99% of integer
overflows
> (it's very rare that a signed integer overflows, but not so
unlikely that
> an unsigned one does).

I do not like that (Java-like) path too much. Why loosing half of
length range?

Re: d-programming-language.org

On Mon, 04 Jul 2011 15:48:12 -0400, bearophile   
wrote:



Steven Schveighoffer:


To the point -- lots of existing D and C code uses the properties of
integer overflow.  If integer overflow is assumed to be an error, then
that code is broken, even though the code *expects* overflow to occur,  
and

in fact might *depend* on it occurring.


In this case you wrap the code in something that allows it to overflow  
without errors, like:


unsafe(overflows) {
// code here
}


Or, use a separate type which throws the errors if you wish.  I don't want  
runtime errors thrown in code that I didn't intend to throw.  most of the  
time, overflows will not occur, so I don't want to go through all my code  
and have to throw these decorations up where I know it's safe.  Besides, D  
is a systems language, and has no business doing checks on every integer  
instruction.  Yes non-relase mode is slower, but we are probably talking  
about a very significant slowdown here.  A lot of integer math happens in  
D.


I think a much more effective fix for the language would be to make slice  
length a signed type.  Then you simply eliminate 99% of integer overflows  
(it's very rare that a signed integer overflows, but not so unlikely that  
an unsigned one does).


At this point, any change to the semantics of the builtin types will be  
extremely disruptive.  We should focus our efforts elsewhere.


-Steve

Re: d-programming-language.org

> I think that's a really good idea.  I'm sure there's a great assembly
> newsgroup or forum where you can post your ideas and mock the D
community
> for the bunch of boobs that we are.

For the record, I have nothing against the D community. Nor against the
D language and I wouldn't spend time here if it would be just to
"mock". Yes, I might sometimes choose the wrong methods (inefficient
ones) when defending some points-of-view. Speaking about irony and
mocking, you made a similar choice in your words above.

Re: D Programming Language Specification ebook

On Mon, 04 Jul 2011 15:22:22 -0400, Walter Bright  
 wrote:



On 7/4/2011 3:40 AM, Jonathan M Davis wrote:

On 2011-07-04 03:24, bearophile wrote:
Maybe older people equate free with "bad", but newer generations are  
used
to find good content for free on Internet. Is D designed for older  
people,

people used to C and C++, that hate JavaScript?


There's a difference between free on the internet and a free book.


Exactly. It may not make rational sense, but it's true.

Free books are regarded today like free software was 20 years ago - it  
must be crap.


Free books does not mean free eBooks.  A free book takes money to create  
every copy, so it can be assumed that if it's free, they are making their  
money some other way (i.e. they are selling you something indirectly).   
But a free eBook does not require money per copy to produce, so its  
quality cannot be judged based on the price (either way, check out  
alphascript publishing).


Considering your target audience, I think it is a very large stretch to  
think they don't understand this concept.


Besides, why can't the book's description say "Copy of the D online  
documentation in kindle format"?  How can anyone "judge" that to be crap?   
This whole argument boggles my mind, there are no non-greed related  
reasons to charge money for this book.


How about this, if you charge any amount of money more than 0, I guarantee  
you will have less than 10% of the downloads than if you gave it away for  
free.  Plus you will alienate people who think they bought an actual D  
book (or worse, think they are getting a deal on Andrei's book) and feel  
like chumps.  That should be great for D's image :P  Iliekcakes will have  
a field day on reddit...


-Steve

Re: d-programming-language.org

Steven Schveighoffer:

> To the point -- lots of existing D and C code uses the properties of  
> integer overflow.  If integer overflow is assumed to be an error, then  
> that code is broken, even though the code *expects* overflow to occur, and  
> in fact might *depend* on it occurring.

In this case you wrap the code in something that allows it to overflow without 
errors, like:

unsafe(overflows) {
// code here
}



Andrei:

>This and others (zero- vs. one-based indexing, closed vs. open intervals etc.) 
>are issues with well-understood tradeoffs that could go either way.<

Integral overflows are not the same thing as indexing and intervals. Such last 
two are equal ways to write the same thing, while overflows are a way to spot a 
class of bugs in code.


>Making a choice in such matters becomes part of a language's ethos.<

Right, and I think D Zen is pro-safety.


>After a while it becomes clear that rehashing such matters without 
>qualitatively new arguments is futile.<

I have answered because you have said wrong things. You have implicitly said 
that good overflow tests are doable with library code, and I have explained why 
you are wrong. This isn't futile.

Bye,
bearophile

Re: d-programming-language.org


On Mon, 04 Jul 2011 14:49:03 -0400, eles  wrote:


I have an idea - how about the notation Uncircular!uint to designate
such a type?
Andrei


Either put it into the standard language, either I have a better one.
what about dropping printf and start using:

mov  ah, 9
int  0x21

instead?

I am sure it can be done. So, why not dropping all D and start to
code back into assembler?


I think that's a really good idea.  I'm sure there's a great assembly  
newsgroup or forum where you can post your ideas and mock the D community  
for the bunch of boobs that we are.



The point is that "it can be done even if the current context" is a
shallow excuse for rejecting better ways to achieve something.


I think the rejection is for the assumption of superiority.  I.e. your way  
isn't better, or even possible, given the existing code base.


To the point -- lots of existing D and C code uses the properties of  
integer overflow.  If integer overflow is assumed to be an error, then  
that code is broken, even though the code *expects* overflow to occur, and  
in fact might *depend* on it occurring.


A more logical path is to build a new type, that's not in any existing  
code base, which handles overflow using exceptions.  Then a developer can  
choose to use this new type if he wants to throw an exception on  
overflow.  If this is not acceptable to you, I suggest you drop it anyways  
-- altering the builtin types is not going to happen.  Ever.


-Steve

Re: d-programming-language.org

> Automatic built-in overflow checking is a choice in the language
design
> space that has distinct consequences. It's easy to execute in the
> compiler so the entry barrier is low. To claim that language designers
> who didn't go that way simply missed the point makes for a weak story.
> Andrei

Well, I was a bit harsh. Apologies.
Force of things is not that "they are easy" but "they are standard".

Re: D Programming Language Specification ebook


On 7/4/2011 3:40 AM, Jonathan M Davis wrote:

On 2011-07-04 03:24, bearophile wrote:

Maybe older people equate free with "bad", but newer generations are used
to find good content for free on Internet. Is D designed for older people,
people used to C and C++, that hate JavaScript?


There's a difference between free on the internet and a free book.


Exactly. It may not make rational sense, but it's true.

Free books are regarded today like free software was 20 years ago - it must be 
crap.

Re: d-programming-language.org


On 7/4/11 1:49 PM, eles wrote:

I have an idea - how about the notation Uncircular!uint to designate
such a type?
Andrei


Either put it into the standard language, either I have a better one.
what about dropping printf and start using:

mov  ah, 9
int  0x21

instead?

I am sure it can be done. So, why not dropping all D and start to
code back into assembler?

The point is that "it can be done even if the current context" is a
shallow excuse for rejecting better ways to achieve something.

BTW, I really look forward to show me an piece of D code that
*cannot* be done in assembler. Then, I ensure you, I will stop
looking for better alternatives to existing ones.


I don't see much merit in the comparison with assembler. Beyond that, 
it's a tad assuming that you presuppose you have an understanding of the 
superiority of automated bounds checking, whereas others are unable to 
get to the same understanding.


Automatic built-in overflow checking is a choice in the language design 
space that has distinct consequences. It's easy to execute in the 
compiler so the entry barrier is low. To claim that language designers 
who didn't go that way simply missed the point makes for a weak story.



Andrei

Re: d-programming-language.org


On 7/3/11 3:50 PM, bearophile wrote:

Andrei:


Safe on top of flexible is the best design. If there is anything
preventing you from defining a type with the behavior you mention,
you may want to file a bug.


I am not a believer. Compile time/run time integral overflows to be
"good enough" need to be built-in, more than associative arrays. How
do you implement the compile-time ones? Run-time integral overflows
need to be tested everywhere you don't explicitly ask for them to not
happen, otherwise you will not catch most bugs.

Bye, bearophile


This and others (zero- vs. one-based indexing, closed vs. open intervals 
etc.) are issues with well-understood tradeoffs that could go either 
way. Making a choice in such matters becomes part of a language's ethos. 
After a while it becomes clear that rehashing such matters without 
qualitatively new arguments is futile.


Andrei

Re: d-programming-language.org

> I have an idea - how about the notation Uncircular!uint to designate
> such a type?
> Andrei

Either put it into the standard language, either I have a better one.
what about dropping printf and start using:

mov  ah, 9
int  0x21

instead?

I am sure it can be done. So, why not dropping all D and start to
code back into assembler?

The point is that "it can be done even if the current context" is a
shallow excuse for rejecting better ways to achieve something.

BTW, I really look forward to show me an piece of D code that
*cannot* be done in assembler. Then, I ensure you, I will stop
looking for better alternatives to existing ones.

Re: D brand identity repository


On 7/4/11 7:56 PM, David Gileadi wrote:

One concern I have is that the D site has a lot of pages, and the
navigation can be a bit hairy. I'd like to see a mockup of a sub-page, a
Phobos or Language Spec page for instance, that shows what
sub-navigation would look like with your design.


Personally, I would suggest using every possible bit of screen real 
estate to make the API documentation more accessible, with a symbol 
hierarchy/search results bar (identifier search like dpldocs.info) to 
the left and the main content area taking the rest of the browser window.


This »DDoc viewer« would be integrated into the rest of the site with a 
thin dark bar at the top of the window, saying »[<<< Back to main site.] 
D Standard Library (Phobos) API documentation« (hey, I already had this 
in my mind before Google changed their design^^).


I have been planning to build something like this for ages, but just 
didn't find enough time to do so…


David

Re: D brand identity repository


On 7/4/11 7:56 PM, David Gileadi wrote:

One concern I have is that the D site has a lot of pages, and the
navigation can be a bit hairy. I'd like to see a mockup of a sub-page, a
Phobos or Language Spec page for instance, that shows what
sub-navigation would look like with your design.


Personally, I would suggest using every possible bit of screen real 
estate to make the API documentation more accessible, with a symbol 
hierarchy/search results bar (identifier search like dpldocs.info) to 
the left and the main content area taking the rest of the browser window.


The »DDoc viewer« would be integrated into the rest of the site with a 
thin bar at the top of the window, saying »[<<< Back to main site.] D 
Standard Library (Phobos) API documentation«, and, most importantly, a 
dark background (hey, I had this idea before Google changed their 
design^^).


I have been planning to build something like this for ages, but just 
didn't find enough time to do so…


David

Re: D brand identity repository

2011-07-04 Thread David Gileadi


On 7/4/11 4:50 AM, James Fisher wrote:

A second draft: http://eegg.github.com/d-brand/mockup2.png

Changes:

Swapped out logo for more conservative change.
Reduction in size of the tabs.
Search bar.
Quick-download thing.  Would have to use OS/arch detection to be effective.
Moved code down into page.  Could expand.

And important point that's not evident is that I'm designing for
variable-width.  That image is for 1600px width, but that could shrink.

On Mon, Jul 4, 2011 at 8:42 AM, James Fisher mailto:jameshfis...@gmail.com>> wrote:

On Sun, Jul 3, 2011 at 11:13 PM, Jonathan M Davis
mailto:jmdavisp...@gmx.com>> wrote:

Overall, I'd say that I have to agree. I like the current look
and feel of d-
programming-language.org , and
I don't see anything wrong with its logo either
(and it looks _way_ better than any of the logos suggested here
IMHO). I'm
sure that the site could be improved, but the kind of stuff
being discussed in
this thread is incredibly subjective and it doesn't generally
seem like much
of an improvement. d-programming-language.org
 is generally a step up from how
www.digitalmars.com  looks, and the
website situation has been improving. So
truth be told, I don't understand this discussion at all. It
seems to me like
it's a bikeshedding argument on website and logo design. I'm
sure that help on
d-programming-language.org 
would be appreciated, but working on redesigning
the website _again_ seems to me like a waste of time which would
be better
spent elsewhere.


I'm not sure what gave the impression that the people in this thread
want to start again from scratch, but that impression seems to be
the source of some hostility.  At least in my case, that's *not*
what I'm proposing.  Pretty much everything here can be categorized
as formalizing, cleaning up, or improving work that's already been done.


I think the fact that the mockups look quite different from the current 
site is generating the heat--something that looks radically different is 
different in peoples' minds, even if it's just a new skin.


I like your mockups, the 2nd one better than the first.  As with some 
other folks, I'm in favor of keeping the existing logo, which I think 
would look good with your design--better than it does on the existing 
site, in my opinion.  I also like that you're designing for variable widths.


One concern I have is that the D site has a lot of pages, and the 
navigation can be a bit hairy.  I'd like to see a mockup of a sub-page, 
a Phobos or Language Spec page for instance, that shows what 
sub-navigation would look like with your design.

Re: D brand identity repository

2011-07-04 Thread Jacob Carlborg


On 2011-07-04 12:50, James Fisher wrote:

A second draft: http://eegg.github.com/d-brand/mockup2.png

Changes:

Swapped out logo for more conservative change.
Reduction in size of the tabs.
Search bar.
Quick-download thing.  Would have to use OS/arch detection to be effective.
Moved code down into page.  Could expand.

And important point that's not evident is that I'm designing for
variable-width.  That image is for 1600px width, but that could shrink.


The size of the tabs are better, still quite high, but now you're 
actually using the space for something else, the search bar.


--
/Jacob Carlborg

Re: D brand identity repository

On Mon, Jul 4, 2011 at 3:14 PM, Jose Armando Garcia wrote:

> Hey, in general I like what you are doing and I find it an improvement on
> the current site.
>
> I quickly looked at your site and I notice the ubuntu logo. I really like
> their logo and what in represent (people holding hands, community,
> solidaridarity).
>

Ubuntu has perhaps the best brand awareness of perhaps any OSS project in
the world:

https://wiki.ubuntu.com/Brand
https://wiki.ubuntu.com/Artwork/Official
http://design.canonical.com/the-toolkit/ubuntu-brand-guidelines/

(It's perhaps no coincidence that it's also the most popular distro.)


> Why don't we use something similar for inspiration for D's logo. For D we
> can use duality and have the two moons of mars represent that duality. For
> example these are dualities that are first class citizens in D: Functional
> vs OO, Stack (struct) vs heap (class), message passing (Tid) vs shared
> memory (shared), runtime polymorphism (inheritance and override)  vs compile
> time (template), etc.
>
> I am currently unable to create an image for inspiration due to lack of
> access to a decent computer and lack of skill creating digital images. I'll
> try to play with the concept and submit some drafts.
>

Everything appreciated!

Re: D Programming Language Specification ebook


On 7/4/11 5:58 AM, Steven Schveighoffer wrote:

My biggest concern with publishing a non-free book based on the web site
is that the *website changes with every release*!

Who wants to pay $5 every time the compiler is released just so you can
have an ebook-style copy of the web data?


I think that's a good argument.

Andrei

Re: D brand identity repository


On 7/4/11 4:14 PM, Jose Armando Garcia wrote:

[…]  Why don't we use something similar for inspiration for
D's logo. For D we can use duality and have the two moons of mars
represent that duality. For example these are dualities that are first
class citizens in D: Functional vs OO, Stack (struct) vs heap (class),
message passing (Tid) vs shared memory (shared), runtime polymorphism
(inheritance and override) vs compile time (template), etc.


I have also been thinking about this, not so much about the duality 
aspect, but simply the fact that D allows you to easily express a number 
of different concepts (template metaprogramming, OOP, functional 
programming, …) and in most cases to freely mix and match as you see 
fit, but I wasn't really able to come up with an idea how to express 
this in logo form.


The only thing coming to my mind was different abstract geometric 
shapes, but I just couldn't get a finished image to appear in front of 
my mind's eye…


David

Re: Strange Error using parameterized opAssign for a struct

2011-07-04 Thread Robert Jacques


On Mon, 04 Jul 2011 05:58:45 -0400, d coder  wrote:


Greetings All

I have a Struct (see minimized code below) which is failing for a simple  
assignment. I am using DMD 2.053, and am getting an error:


implicit.d(14): Error: cannot implicitly convert expression (foo1) of  
type Foo!(4) to Foo!(NN)


Am I doing something wrong, or have I hit a DMD bug? Kindly note that  
this happens only when I parameterize the struct using an Integral  
parameter, and works file when using string as parameter (as with struct  
Bar in the code).


Regards
- Puneet


Yes and No. DMD has trouble deducing the correct template parameters for  
implicit function template instantiating when you make the template  
parameter the input to another template. The solution is to match a  
general type T and constrain it. (DMD can do these more complex matches  
inside an is expression, etc. So you can rewrite your code as:


// File implicit.d
struct Foo (size_t N) {
  void opAssign (T:Foo!NN,size_t NN)(T f) {/*do nothing*/}
}
struct Bar (string S) {
  void opAssign (string SS)(Bar!(SS) f) {/*do nothing*/}
}
void main() {
  Bar!"BAR1" bar1;
  Bar!"BAR2" bar2;
  bar2 = bar1;  // this compiles fine
  Foo!4 foo1;
  Foo!4 foo2;
  foo2 = foo1;  // Now compiles
}

Also, if you want to instantiate a Foo!NN, IIRC there's similar bug where  
the type becomes Foo!NN and not Foo!4. The solution is to use Foo!(NN+0)  
(or T) instead.

Re: D brand identity repository

2011-07-04 Thread Jose Armando Garcia

Hey, in general I like what you are doing and I find it an improvement  
on the current site.


I quickly looked at your site and I notice the ubuntu logo. I really  
like their logo and what in represent (people holding hands,  
community, solidaridarity). Why don't we use something similar for  
inspiration for D's logo. For D we can use duality and have the two  
moons of mars represent that duality. For example these are dualities  
that are first class citizens in D: Functional vs OO, Stack (struct)  
vs heap (class), message passing (Tid) vs shared memory (shared),  
runtime polymorphism (inheritance and override)  vs compile time  
(template), etc.


I am currently unable to create an image for inspiration due to lack  
of access to a decent computer and lack of skill creating digital  
images. I'll try to play with the concept and submit some drafts.  
Maybe the yin-yang symbol can be of inspiration.


Note: I have noticed that I have an attraction/affinity to circles

Em 04/07/2011, às 07:50, James Fisher   
escreveu:



A second draft: http://eegg.github.com/d-brand/mockup2.png

Changes:

Swapped out logo for more conservative change.
Reduction in size of the tabs.
Search bar.
Quick-download thing.  Would have to use OS/arch detection to be  
effective.

Moved code down into page.  Could expand.

And important point that's not evident is that I'm designing for  
variable-width.  That image is for 1600px width, but that could  
shrink.


On Mon, Jul 4, 2011 at 8:42 AM, James Fisher  
 wrote:
On Sun, Jul 3, 2011 at 11:13 PM, Jonathan M Davis  
 wrote:
Overall, I'd say that I have to agree. I like the current look and  
feel of d-
programming-language.org, and I don't see anything wrong with its  
logo either
(and it looks _way_ better than any of the logos suggested here  
IMHO). I'm
sure that the site could be improved, but the kind of stuff being  
discussed in
this thread is incredibly subjective and it doesn't generally seem  
like much
of an improvement. d-programming-language.org is generally a step up  
from how
www.digitalmars.com looks, and the website situation has been  
improving. So
truth be told, I don't understand this discussion at all. It seems  
to me like
it's a bikeshedding argument on website and logo design. I'm sure  
that help on
d-programming-language.org would be appreciated, but working on  
redesigning
the website _again_ seems to me like a waste of time which would be  
better

spent elsewhere.

I'm not sure what gave the impression that the people in this thread  
want to start again from scratch, but that impression seems to be  
the source of some hostility.  At least in my case, that's *not*  
what I'm proposing.  Pretty much everything here can be categorized  
as formalizing, cleaning up, or improving work that's already been  
done.

Re: D brand identity repository

2011-07-04 Thread Daniel Gibson

Am 04.07.2011 12:50, schrieb James Fisher:
> A second draft: http://eegg.github.com/d-brand/mockup2.png
> 
> Changes:
> 
> Swapped out logo for more conservative change.
> Reduction in size of the tabs.
> Search bar.
> Quick-download thing.  Would have to use OS/arch detection to be effective.
> Moved code down into page.  Could expand.
> 
> And important point that's not evident is that I'm designing for
> variable-width.  That image is for 1600px width, but that could shrink.
> 

I think the old logo (maybe slightly modified) should be kept at the
homepage.
At least I see the proposed logo as a simpler version of the old logo
that should be used if the old logo is to shiny for the purpose or can't
be scaled down enough etc.

Cheers,
- Daniel

Re: D Programming Language Specification ebook

On Sun, 03 Jul 2011 22:36:26 -0400, Daniel Gibson   
wrote:



And please provide that ebook as PDF or whatever on the D homepage so
people with other ebook readers (or iPads) can use it as well. :-)


http://www.amazon.com/gp/feature.html/ref=kcp_ipad_mkt_lnd?docId=1000490441

Similar apps exist for all the mobile platforms.

Considering that the documentation is all boost-licensed, anyone may build  
(and sell!) an ebook in a competing format.  I think it's reasonable to  
select the most popular format, and let people create other formats if  
they so desire.


-Steve

Re: D brand identity repository

On Sat, 02 Jul 2011 03:42:42 -0400, James Fisher   
wrote:


On Fri, Jul 1, 2011 at 6:18 PM, Steven Schveighoffer  
wrote:



I think you are way overthinking this...



I've never quite understood what "overthinking" actually means.  If you  
mean

exploring all possible trains of thought the viewer, I'll take that as a
compliment.  By all means disagree with what I say -- it's either valid  
or

it's not (it may well not be!).


Then I disagree -- the case you bring up is obscure, plus it makes an  
assumption that having to explain historical references in the logo is a  
negative.


The main focus of the logo is the D, the moons might generate some trivia  
questions, but is that really a turnoff?




rule #1 -- the logo should have the letter 'D' in it.


and, um... that's it :)



That is most definitely *not* it.  By your specification, would you be  
happy

with just the 'D' from Comic Sans?


No.  But it would qualify as a D logo candidate -- it has a D in it.  I  
didn't imply that we should randomly select from all possible logos that  
have a D in it to be our logo.  I was saying that we should not make any  
other rules disqualifying a logo because of some obscure invented  
situation that might occur.  As long as there's a D in it, it can be  
considered as a logo, and if it generates quizzical looks, who cares?



There is a huge number of explicit and implicit rules and guidelines to
consider when creating the one image that will represent your project for
time immemorial.  That's why there are books, websites, careers forged on
this.


As a non-designer, this is the *only* rule I would go by to disqualify a  
logo for D -- if it doesn't have a D in it, I don't think it should be the  
logo for D.  I'll leave all the asthetics and other things up to the real  
designers.  I can only say what I like and don't like, I have no skill to  
design such things.


-Steve

Re: D brand identity repository

On Sun, 03 Jul 2011 10:52:07 -0400, Andrei Alexandrescu  
 wrote:



On 7/3/11 7:15 AM, James Fisher wrote:



On Sun, Jul 3, 2011 at 11:47 AM, Jacob Carlborg mailto:d...@me.com>> wrote:

On 2011-07-02 23:01, James Fisher wrote:

So, here's a website mockup:
http://eegg.github.com/d-__brand/mockup.png


Comments appreciated.


In general I like it. I think the top tabs are a little too big. You
could cut the height in half I think, it's wasting a too much
vertical space. You can easily cut off 30px above and below the text
in the tabs.


That is true, though I do have a few reasons for keeping 'em big:

- I think the composition works better with it being a half or a third
of the height of the sand-color banner.
- potentially, a second layer of links could be introduced.  (Though in
general I shy away from multi-level top-level links as over-engineered,
unless the site is really complex, which it's not.)
- on other pages, e.g. the docs, I'm considering having the logo in the
dark banner (at the same x-pos).  This would require some space.
- last but not least, it's the web, not paper, and we have all the space
we want for free!

I would be nice to see a mouckup of one page from the language
reference and one from the library reference, for example:

http://d-programming-language.__org/lex.html

http://d-programming-language.__org/phobos/std_string.html



I'll come up with those when I stop playing around with Inkscape, and
mock up in HTML/CSS.


One thing that's going somewhat unnoticed in this discussion is that the  
site is at the end of a major redesign cycle during which people in this  
group gave extensive input on the logo, the color scheme, the fonts, the  
page design - pretty much all aspects of the website. I find it  
surprising that all that is now as if it never existed.


The page design hasn't changed very much.  As far as I recall (and I  
didn't participate a lick in the discussions), no major site design  
discussions occurred.  But maybe I just didn't look at any of the  
alternatives when they were posted.


If it's worth anything, I like the coloring and logo scheme of the current  
site, but I like the design of James' mockup better.


-Steve

Re: D Programming Language Specification ebook

On Sun, 03 Jul 2011 22:11:10 -0400, Walter Bright  
 wrote:


I think it would be a good move to make a kindle ebook out of the  
specification on the web site. Not only will it be convenient for those  
who wish to peruse the spec using a kindle, it will be helpful for  
marketing etc.


The difficulty is that if I put the ebook up on Amazon for free, people  
tend to equate free with "crap". It needs to have a price on it to be  
taken seriously.


This notion is outdated.  There are multiple free ebooks available on  
iBook (the iPad/iPhone book store) and some of them are classics.


The thing is, the vast majority of people are not going to discover D via  
Amazon, read the ebook spec, then go play with D by downloading the  
compiler.  The most likely scenario is:


1. Discovering D via word of mouth, or looking for alternatives to other  
languages that have design flaws (like C++!)

2. Playing with the compiler, building programs, reading the online docs.
3. Wishing there was an ebook form of the documentation, and seeing one  
exists via some link on the home page, or asking on the newsgroups.


At this point, do you really think that such a coder cares whether the  
ebook is free?  IMO making it *NOT* free is likely to turn off that coder  
from D, since they likely are already familiar with the site, and they  
will instantly know the ebook is just an automated reprint of the web site.


But if I put a price on it, people will be demotivated to continue  
contributing to it, because they'll perceive someone else profiting from  
their work.


This is not a big concern for me.  I'd be more worried about D's  
reputation being sullied by trying to make a profit out of obviously  
freely available information.


My biggest concern with publishing a non-free book based on the web site  
is that the *website changes with every release*!


Who wants to pay $5 every time the compiler is released just so you can  
have an ebook-style copy of the web data?


Is it difficult to make an ebook for kindle?  If it's automated, would the  
automation be available as open source code?  If so, why wouldn't people  
just make their own ebook for kindle?


Technically, you could not stop someone else from doing this, since the  
license is Boost, so what would you do if someone created a free version  
with *exactly the same information* to compete with your non-free one?


My recommendation -- release it for free.  There are zero reasons to  
charge money for it.


-Steve

Re: D brand identity repository

A second draft: http://eegg.github.com/d-brand/mockup2.png

Changes:

Swapped out logo for more conservative change.
Reduction in size of the tabs.
Search bar.
Quick-download thing.  Would have to use OS/arch detection to be effective.
Moved code down into page.  Could expand.

And important point that's not evident is that I'm designing for
variable-width.  That image is for 1600px width, but that could shrink.

On Mon, Jul 4, 2011 at 8:42 AM, James Fisher  wrote:

> On Sun, Jul 3, 2011 at 11:13 PM, Jonathan M Davis wrote:
>>
>> Overall, I'd say that I have to agree. I like the current look and feel of
>> d-
>> programming-language.org, and I don't see anything wrong with its logo
>> either
>> (and it looks _way_ better than any of the logos suggested here IMHO). I'm
>> sure that the site could be improved, but the kind of stuff being
>> discussed in
>> this thread is incredibly subjective and it doesn't generally seem like
>> much
>> of an improvement. d-programming-language.org is generally a step up from
>> how
>> www.digitalmars.com looks, and the website situation has been improving.
>> So
>> truth be told, I don't understand this discussion at all. It seems to me
>> like
>> it's a bikeshedding argument on website and logo design. I'm sure that
>> help on
>> d-programming-language.org would be appreciated, but working on
>> redesigning
>> the website _again_ seems to me like a waste of time which would be better
>> spent elsewhere.
>
>
> I'm not sure what gave the impression that the people in this thread want
> to start again from scratch, but that impression seems to be the source of
> some hostility.  At least in my case, that's *not* what I'm proposing.
>  Pretty much everything here can be categorized as formalizing, cleaning up,
> or improving work that's already been done.
>

Re: D Programming Language Specification ebook

2011-07-04 Thread Johann MacDonagh


On 7/4/2011 6:17 AM, Brad Roberts wrote:

On 7/4/2011 3:14 AM, Johann MacDonagh wrote:

On 7/4/2011 5:52 AM, Walter Bright wrote:

On 7/4/2011 1:50 AM, Johann MacDonagh wrote:



If you set a price we'd have to go through each page and clean them up
/ update
some for D2, etc... Donations make it nice because you can release newer
versions and donaters can update their copy without paying again.


The idea is to generate the ebook automatically from the web sources.


Right, but there are some pages that need updating. The FAQ (from a recent NG post), is 
one. The "Handling errors" page
probably needs some examples. The DLL example code is outdated as well IIRC. I 
just think guaranteeing that purchasers
can get more up-to-date versions as pages are tweaked would be a nice touch, 
and I'm not sure how well Amazon handles that.


The pages need to be updated completely independently from any book that may or 
may not be published and independently
from any amount that might be charged.  It's a matter of time/resources.  
Please submit bug report and/or pull requests
with proposed changes.

Later,
Brad


I wasn't complaining about the current quality. I just wanted to point 
out if the site were to be packaged up and sold there should be a easy 
way for purchasers to get an updated version as the site gets cleaned up.

Re: D Programming Language Specification ebook

2011-07-04 Thread Jonathan M Davis

On 2011-07-04 03:24, bearophile wrote:
> Walter:
> > The difficulty is that if I put the ebook up on Amazon for free, people
> > tend to equate free with "crap". It needs to have a price on it to be
> > taken seriously.
> 
> Maybe older people equate free with "bad", but newer generations are used
> to find good content for free on Internet. Is D designed for older people,
> people used to C and C++, that hate JavaScript?

There's a difference between free on the internet and a free book. Most people 
expect things on the internet to be free and books to cost money. And as soon 
as you're dealing with something that normally costs money being free, many 
people think that free item is junk or a scam of some kind. How prevalent such 
thinking would be about an e-book on D, I don't know. But there's a definite 
difference between free online and a free book.

- Jonathan M Davis

Re: D Programming Language Specification ebook

Walter:

> The difficulty is that if I put the ebook up on Amazon for free, people tend 
> to 
> equate free with "crap". It needs to have a price on it to be taken seriously.

Maybe older people equate free with "bad", but newer generations are used to 
find good content for free on Internet. Is D designed for older people, people 
used to C and C++, that hate JavaScript?

Bye,
bearophile

Re: D Programming Language Specification ebook

2011-07-04 Thread Brad Roberts

On 7/4/2011 3:14 AM, Johann MacDonagh wrote:
> On 7/4/2011 5:52 AM, Walter Bright wrote:
>> On 7/4/2011 1:50 AM, Johann MacDonagh wrote:
> 
>>> If you set a price we'd have to go through each page and clean them up
>>> / update
>>> some for D2, etc... Donations make it nice because you can release newer
>>> versions and donaters can update their copy without paying again.
>>
>> The idea is to generate the ebook automatically from the web sources.
> 
> Right, but there are some pages that need updating. The FAQ (from a recent NG 
> post), is one. The "Handling errors" page
> probably needs some examples. The DLL example code is outdated as well IIRC. 
> I just think guaranteeing that purchasers
> can get more up-to-date versions as pages are tweaked would be a nice touch, 
> and I'm not sure how well Amazon handles that.

The pages need to be updated completely independently from any book that may or 
may not be published and independently
from any amount that might be charged.  It's a matter of time/resources.  
Please submit bug report and/or pull requests
with proposed changes.

Later,
Brad

Re: D Programming Language Specification ebook

2011-07-04 Thread Johann MacDonagh


On 7/4/2011 5:52 AM, Walter Bright wrote:

On 7/4/2011 1:50 AM, Johann MacDonagh wrote:

On 7/3/2011 10:11 PM, Walter Bright wrote:

What do you all think? $0? $4.99? $9.99?


What about skipping Amazon and putting it up on
d-programming-language.org and
ask for donations? I think Paypal will handle the processing for you
for free if
you show you're not doing it for profit.


People at the airport press a "free gift" on me, and then harangue me
for a donation. I think that's the wrong image for D. People shouldn't
be made to feel guilty about using D and not making a donation. I know
it would turn me off, at least.


Yeah, I suppose. I guess if you follow the progit model (like you 
suggested) and said "Support the D community!" that would essentially be 
the same thing




If you set a price we'd have to go through each page and clean them up
/ update
some for D2, etc... Donations make it nice because you can release newer
versions and donaters can update their copy without paying again.


The idea is to generate the ebook automatically from the web sources.


Right, but there are some pages that need updating. The FAQ (from a 
recent NG post), is one. The "Handling errors" page probably needs some 
examples. The DLL example code is outdated as well IIRC. I just think 
guaranteeing that purchasers can get more up-to-date versions as pages 
are tweaked would be a nice touch, and I'm not sure how well Amazon 
handles that.

Strange Error using parameterized opAssign for a struct

2011-07-04 Thread d coder

Greetings All

I have a Struct (see minimized code below) which is failing for a simple
assignment. I am using DMD 2.053, and am getting an error:

> implicit.d(14): Error: cannot implicitly convert expression (foo1) of type
Foo!(4) to Foo!(NN)

Am I doing something wrong, or have I hit a DMD bug? Kindly note that this
happens only when I parameterize the struct using an Integral parameter, and
works file when using string as parameter (as with struct Bar in the code).

Regards
- Puneet

// File implicit.d
struct Foo (size_t N) {
  void opAssign (size_t NN)(Foo!(NN) f) {/*do nothing*/}
}
struct Bar (string S) {
  void opAssign (string SS)(Bar!(SS) f) {/*do nothing*/}
}
void main() {
  Bar!"BAR1" bar1;
  Bar!"BAR2" bar2;
  bar2 = bar1; // this compiles fine
  Foo!4 foo1;
  Foo!4 foo2;
  foo2 = foo1; // compilation error
}

Re: D Programming Language Specification ebook


On 7/4/2011 12:30 AM, Jacob Carlborg wrote:

I hope it will not be limited to the Kindle and Amazon.


If there's a demand, we can deliver!

Re: D Programming Language Specification ebook


On 7/4/2011 1:50 AM, Johann MacDonagh wrote:

On 7/3/2011 10:11 PM, Walter Bright wrote:

What do you all think? $0? $4.99? $9.99?


What about skipping Amazon and putting it up on d-programming-language.org and
ask for donations? I think Paypal will handle the processing for you for free if
you show you're not doing it for profit.


People at the airport press a "free gift" on me, and then harangue me for a 
donation. I think that's the wrong image for D. People shouldn't be made to feel 
guilty about using D and not making a donation. I know it would turn me off, at 
least.




If you set a price we'd have to go through each page and clean them up / update
some for D2, etc... Donations make it nice because you can release newer
versions and donaters can update their copy without paying again.


The idea is to generate the ebook automatically from the web sources.

Re: D Programming Language Specification ebook


On 7/4/2011 12:50 AM, James Fisher wrote:

On Mon, Jul 4, 2011 at 3:11 AM, Walter Bright mailto:newshou...@digitalmars.com>> wrote:

I think it would be a good move to make a kindle ebook out of the
specification on the web site.


Forgive my stupidity, but what exact content are we talking about here?  The
language and library references?


Yes.

Re: D Programming Language Specification ebook

2011-07-04 Thread Johann MacDonagh


On 7/3/2011 10:11 PM, Walter Bright wrote:

What do you all think? $0? $4.99? $9.99?


What about skipping Amazon and putting it up on 
d-programming-language.org and ask for donations? I think Paypal will 
handle the processing for you for free if you show you're not doing it 
for profit.


If you set a price we'd have to go through each page and clean them up / 
update some for D2, etc... Donations make it nice because you can 
release newer versions and donaters can update their copy without paying 
again.

Re: D Programming Language Specification ebook

On Mon, Jul 4, 2011 at 3:11 AM, Walter Bright wrote:

> I think it would be a good move to make a kindle ebook out of the
> specification on the web site.


Forgive my stupidity, but what exact content are we talking about here?  The
language and library references?

Re: D brand identity repository

On Sun, Jul 3, 2011 at 11:13 PM, Jonathan M Davis wrote:
>
> Overall, I'd say that I have to agree. I like the current look and feel of
> d-
> programming-language.org, and I don't see anything wrong with its logo
> either
> (and it looks _way_ better than any of the logos suggested here IMHO). I'm
> sure that the site could be improved, but the kind of stuff being discussed
> in
> this thread is incredibly subjective and it doesn't generally seem like
> much
> of an improvement. d-programming-language.org is generally a step up from
> how
> www.digitalmars.com looks, and the website situation has been improving.
> So
> truth be told, I don't understand this discussion at all. It seems to me
> like
> it's a bikeshedding argument on website and logo design. I'm sure that help
> on
> d-programming-language.org would be appreciated, but working on
> redesigning
> the website _again_ seems to me like a waste of time which would be better
> spent elsewhere.


I'm not sure what gave the impression that the people in this thread want to
start again from scratch, but that impression seems to be the source of some
hostility.  At least in my case, that's *not* what I'm proposing.  Pretty
much everything here can be categorized as formalizing, cleaning up, or
improving work that's already been done.

Re: D Programming Language Specification ebook

2011-07-04 Thread Jacob Carlborg


On 2011-07-04 04:11, Walter Bright wrote:

I think it would be a good move to make a kindle ebook out of the
specification on the web site. Not only will it be convenient for those
who wish to peruse the spec using a kindle, it will be helpful for
marketing etc.

The difficulty is that if I put the ebook up on Amazon for free, people
tend to equate free with "crap". It needs to have a price on it to be
taken seriously.

But if I put a price on it, people will be demotivated to continue
contributing to it, because they'll perceive someone else profiting from
their work.

Perhaps proceeds from it should be put towards other promotions of D,
like maybe a conference? More contests with prizes?

What do you all think? $0? $4.99? $9.99?

And yes, the content will be identical to that on the website, just
formatted for the kindle.


I hope it will not be limited to the Kindle and Amazon.

--
/Jacob Carlborg

Re: D brand identity repository

On Sun, Jul 3, 2011 at 7:20 PM, Andrej Mitrovic
wrote:

> I'd rather not have a website where I have to click on 10 links to get
> to the information I need. The current site has everything on its
> homepage, and that's a good thing. Fuck these iPad-friendly
> poser-sites.
>

My, aren't you unfriendly :-)

Re: D brand identity repository