Re: Add imports in examples?

[Andrej Mitrovic]

Ok, see some examples do have imports, here's one few lines down:

import std.conv;
int a;
void fun() { auto b = to!(string)(a); }
auto r = benchmark!fun();
writefln("Milliseconds to call fun() %s times: %s",
r[0], r[1][0].to!("msecs", int));

I don't see a reason to put imports in some places, but leave them out
in others. A little consistency would be nice, methinks.

Add imports in examples?

[Andrej Mitrovic]

Since 2.054 will allow function-local imports we could add imports in
examples. E.g. the upcoming std.benchmark module has this example:


void foo()
{
StopWatch sw;
enum n = 100;
TickDuration[n] times;
TickDuration last = TickDuration.from!"seconds"(0);
static void bar() {} //@Add
foreach(i; 0..n)
{
   sw.start(); //start/resume mesuring.
   foreach(unused; 0..1_000_000)
   bar();
   sw.stop();  //stop/pause measuring.
   //Return value of peek() after having stopped are the always same.
   writeln((i + 1) * 1_000_000, " times done, lap time: ",
   sw.peek().msecs, "[ms]");
   times[i] = sw.peek() - last;
   last = sw.peek();
}
real sum = 0;
// When you want to know the number of seconds,
// you can use properties of TickDuration.
// (seconds, mseconds, useconds, hnsecs)
foreach(t; times)
   sum += t.hnsecs;
writeln("Average time: ", sum/n, " hnsecs");
}


But it's missing an import to std.conv and std.stdio. If there was an
import right there at the top the example is instantly compilable:


void foo()
{
import core.time;  // added
import std.stdio;   // added
StopWatch sw;
...
---

There's also a missing function definition in that example but I'll
make a note for this on github.

Re: D brand identity repository

[Daniel Gibson]

Am 01.07.2011 18:02, schrieb James Fisher:
> Note that Python's logo is not the word
> "python" made out of snakes, for example. 

Python's logo is a (pair of stylized) python(s), and D's logo contains a
"D", so whats the difference?
It's not like we spell out "Dee" or something (although this may be
doable with the moons as 'e's).
If the languages name was "Mars" (like originally intended) just having
mars as a logo (like digitalmars) would make sense, but not for a
language named "D". I think it's important that the logo makes sense for
somebody who is not deeply familiar with D and its (digital)mars origin.

Cheers,
- Daniel

Re: Shortcut evaluation for hierarchy of in contracts

[simendsjo]

On 02.07.2011 01:32, Robert Jacques wrote:

On Fri, 01 Jul 2011 02:39:29 -0400, Jens Mueller 
wrote:

Robert Jacques wrote:

On Thu, 30 Jun 2011 06:42:57 -0400, Jens Mueller
 wrote:

>bearophile wrote:
>>Jens Mueller:
>>
>>> unittest {
>>> class Base {
>>> void foo(uint i)
>>> in { assert(i <= 10); }
>>> body { }
>>> }
>>>
>>> class Sub : Base {
>>> override void foo(uint i)
>>> in { assert(i <= 5); } // fails to require less
>>but I won't know
>>> body
>>> {
>>> assert(i <= 5); // fails here because in contract
>>wasn't checked
>>> }
>>> }
>>>
>>> auto s = new Sub;
>>> //s.foo(10); // fails as expected
>>> s.foo(7); // due to shortcut evaluation of in contracts
>>this call passes all contracts
>>> }
>>
>>I think it's a DMD bug, fit for Bugzilla if not already present.
>
>The shortcut evaluation is specified in TDPL. That's why I assume the
>behavior is intended.
>
>Jens

A subclass must be able to handle all the inputs the base class
accepts, otherwise it isn't true polymorphism anymore. Not being
able to use Sub where Base is expected, and maybe only Base was
tested, can lead to major bugs.


So you agree that the current behavior is error-prone?


No. I think the current behavior is correct. In fact, if anything, D
shouldn't allow you to define an in contract on any override method. A
Sub is a Base and therefore must be able to handle all inputs that are
valid for a Base.


Have to agree. By tightening the contracts in subclasses, you'll break 
Liskov substitution principle.

Re: Shortcut evaluation for hierarchy of in contracts

[Robert Jacques]

On Fri, 01 Jul 2011 02:39:29 -0400, Jens Mueller   
wrote:

Robert Jacques wrote:

On Thu, 30 Jun 2011 06:42:57 -0400, Jens Mueller
 wrote:

>bearophile wrote:
>>Jens Mueller:
>>
>>> unittest {
>>> class Base {
>>> void foo(uint i)
>>> in { assert(i <= 10); }
>>> body { }
>>> }
>>>
>>> class Sub : Base {
>>> override void foo(uint i)
>>> in { assert(i <= 5); } // fails to require less
>>but I won't know
>>> body
>>> {
>>> assert(i <= 5); // fails here because in contract
>>wasn't checked
>>> }
>>> }
>>>
>>> auto s = new Sub;
>>> //s.foo(10); // fails as expected
>>> s.foo(7); // due to shortcut evaluation of in contracts
>>this call passes all contracts
>>> }
>>
>>I think it's a DMD bug, fit for Bugzilla if not already present.
>
>The shortcut evaluation is specified in TDPL. That's why I assume the
>behavior is intended.
>
>Jens

A subclass must be able to handle all the inputs the base class
accepts, otherwise it isn't true polymorphism anymore. Not being
able to use Sub where Base is expected, and maybe only Base was
tested, can lead to major bugs.


So you agree that the current behavior is error-prone?


No. I think the current behavior is correct. In fact, if anything, D  
shouldn't allow you to define an in contract on any override method. A Sub  
is a Base and therefore must be able to handle all inputs that are valid  
for a Base.

Re: Faster accurate printing of floating-point numbers

[Don]

Daniel Gibson wrote:

Hi,

dunno if D maybe already uses something like that, but I just stumbled
upon this article and thought it may be of interest:
http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/

The article claims that the discussed algorithm is about 5 times faster
than what the GNU libc uses in printf.

Cheers,
- Daniel


Thanks, that's a good paper.

Re: Shortcut evaluation for hierarchy of in contracts

[Walter Bright]

On 7/1/2011 9:56 AM, Daniel Murphy wrote:

If I understand this correctly, you think the following code should be
perfectly valid:

class A { void func(uint x) in { assert(x<  10); } body {} }
class B : A { void func(uint x) in { assert(x == 50); } body {} }


Yes.


If A.func can be called with any value 0..10, why is it legal to override it
with a function that can't accept these values?


It isn't. An overriding function *must* accept all input that the overridden 
function does.


In other words, overriding functions accept a superset of the input, and deliver 
a subset of the output.




Can you give an example
where accepting input that is not a superset of the overriden function's
possible input is valid?


No.

Re: Shortcut evaluation for hierarchy of in contracts

[Walter Bright]

On 7/1/2011 9:24 AM, Timon Gehr wrote:

All arguments given for a runtime check of this kind are the result of a
misunderstanding of contract inheritance. The 'in'-contract of an overridden
method merely extends the in-contract of the parent's method, and does not
override it. In that way, the compiler statically ensures that the precondition 
of
a child cannot possibly fail if the parent's passed. Thats the sole reason for 
the
short-circuiting behavior.

The child's contract says: If my parent's contract failed, I can still satisfy 
the
postcondition, if this _alternative_ precondition holds. But it does not
necessarily have to pass on all input the parent passes on, because it does not
even get checked if the parent's precondition holds.

If you add such a check, the child's in-contract will have to carefully 
duplicate
the parent's precondition in order not to provoke a nonsensical runtime-error.
Adding such a check would make D's contracts unusable in anything but the most
trivial cases.

(Analogously, the child's 'out'-contract does not have to re-check the parent's
postcondition.)



Right.

Re: Shortcut evaluation for hierarchy of in contracts

[Daniel Murphy]

"Walter Bright"  wrote in message 
news:iul14g$1dfs$2...@digitalmars.com...
> On 7/1/2011 6:53 AM, Daniel Murphy wrote:
>> To enforce this, the compiler should give an error if a base function's
>> precondition passes but a derived precondition does not.
>
> No, it should not. Only one of the contracts needs to pass.
>
>> The requirement is not really that any 'in' contract passing is good 
>> enough,
>
> Yes, it is.
>
>> it's just assumed that all preconditions on inherited functions will pass 
>> if
>> the base contract does.
>
> Only one contract needs to pass.

Yeah, I did get this eventually. 

Re: Shortcut evaluation for hierarchy of in contracts

[Walter Bright]

On 7/1/2011 8:16 AM, David Nadlinger wrote:

In my opinion, one *is* able to declare the child contract invalid in case 2 –
if the parent passes but the child fails, it certainly violates the »loosening«
property of in contract inheritance. If you don't think so, could you please
explain your doubts in more detail?


The rule for in contracts is:

pass = P || C;

The rule for out contracts is:

pass = P && C;

Re: Shortcut evaluation for hierarchy of in contracts

[Walter Bright]

On 7/1/2011 6:53 AM, Daniel Murphy wrote:

To enforce this, the compiler should give an error if a base function's
precondition passes but a derived precondition does not.


No, it should not. Only one of the contracts needs to pass.


The requirement is not really that any 'in' contract passing is good enough,


Yes, it is.


it's just assumed that all preconditions on inherited functions will pass if
the base contract does.


Only one contract needs to pass.

Re: Shortcut evaluation for hierarchy of in contracts

[Walter Bright]

On 7/1/2011 1:10 AM, Jens Mueller wrote:

Yes. But the problem with passing only one of the in contracts is that
it is error-prone because it *assumes* that for in contracts the
requirements are widened. But what if the programmer fails at loosening
a derived in contract, i.e. he restricted it. In the current setting the
programmer won't know that he did an error. And with deep inheritance
hierarchies it gets more complicated to have all the contracts of super
classes in mind.
Why not check all in contracts to make sure that they follow the
loosening rule? Why not enforce the loosing rule?


The loosening rule is that one of the in contracts must pass. That's exactly 
what it does. As soon as one passes, there is no need to check the rest.

Re: Shortcut evaluation for hierarchy of in contracts

[Daniel Murphy]

"Timon Gehr"  wrote in message 
news:iukvrl$1c1c$1...@digitalmars.com...
>
> Sure, if you remember the Foo/Qux example (Foo is parent, Qux is child, 
> method
> bar(a,b), parent requires a>0 child requires else b>0)
>
> void main(){
>  auto a=new Foo, b=new Qux;
>  a.bar(1,-1);//ok
>  b.bar(1,-1);//ok, child works everywhere parent works
>  //a.bar(-1,1);// not ok
>  //b.bar(-1,-1)// not ok
>  b.bar(-1,1);//ok, child works too if b>0
> }

And it finally clicks!  Thanks for taking the time to explain it to me.
(If only I'd got it sooner, I wouldn't have spent the last two hours 
implementing my behaviour in the compiler) 

Re: D brand identity repository

[Mafi]

Am 01.07.2011 19:21, schrieb Mafi:

Am 01.07.2011 18:08, schrieb James Fisher:

On Thu, Jun 30, 2011 at 8:35 PM, Mafi mailto:m...@example.org>> wrote:

This is my try.
What do you guys think about it?


So, I do think yours has merit. The one gripe I have with it is a lack
of obviousness. Compare:

New Python user: "say, why's your logo made of snakes?"
Pythoneer: "..."

where "..." is "Well, the creator of the language was a fan of Monty
Python. So he decided to call the language python. Now, when they needed
a logo, they just decieded to reinterpret 'python' and made the logo out
of snakes. When now somebody sees a snake in programming context he
thinks of 'python', the only language whose name *sounds* like the name
of a snake."

But you're right. With 'python' it's anyways a lot more obvious than
with 'D'.

In the last sentence I mean the D logo and the python logo and the 
planets and snakes respectively.

Re: D brand identity repository

[Mafi]

Am 01.07.2011 18:08, schrieb James Fisher:

On Thu, Jun 30, 2011 at 8:35 PM, Mafi mailto:m...@example.org>> wrote:

This is my try.
What do you guys think about it?


So, I do think yours has merit.  The one gripe I have with it is a lack
of obviousness.  Compare:

New Python user: "say, why's your logo made of snakes?"
Pythoneer: "..."
where "..." is "Well, the creator of the language was a fan of Monty 
Python. So he decided to call the language python. Now, when they needed 
a logo, they just decieded to reinterpret 'python' and made the logo out 
of snakes. When now somebody sees a snake in programming context he 
thinks of 'python', the only language whose name *sounds* like the name 
of a snake."


But you're right. With 'python' it's anyways a lot more obvious than 
with 'D'.

Re: Shortcut evaluation for hierarchy of in contracts

[Timon Gehr]

Daniel Murphy wrote:"Timon Gehr"  wrote in message
>news:iukptu$10nq$1...@digitalmars.com...
>> Daniel Murphy wrote:
>>> "Timon Gehr"  wrote in message
>>> news:iukoge$u82$1...@digitalmars.com...
 How would you catch it? I am sure it cannot be caught trivially:

 There are 4 possibilities:
 1. Both parent and child contract would pass.
 2. Parent passes, child would fail.
 3. Parent fails, child passes.
 4. Parent fails, child fails.

>>> In case 2, the contract is invalid.
>>>
>>> In reality, the overriding graph forms a tree, and the contract is
>>> invalid
>>> if any precondition passes if its parent's precondition fails. (the root
>>> being the most derived function)
>>
>> That is case 3. And it is perfectly valid.
>>
>
> Sorry for the mixin of terms, I meant parent in the tree, which is the
> opposite direction to parent in inheritance.
>
>>>
>>> It is definately possible to implement runtime checking to enforce this.
>>
>> My first post on the subject features an example where case 2 can occur
>> and be
>> valid. Have a look at it please.
>>
>
> I disagree.  If the child's in condition requires something that the
> parent's didn't, you've just tightened the precondition.
>
> If I understand correctly, it's equivilent to:
> parent: require a is greater than 0
> child: require b is greater than 0

It is equivalent to:
parent: require a is greater than 0
child: ... else require b is greater than 0


>
> In this case, the parent allows more values of b than the child does, so the
> precondition has been tightened.

No, the child allows arbitrary values of b if a>0, due to the short-circuiting
behavior.

>
[snip.]
>>
>> Again: in contract of child != precondition of child
>>
>
> Ok, I doubt I used the right terms everywhere.

I didn't either :).

> Reading your other post, I'm starting to think we just have different ideas
> of how contract inheritance should work.  I _think_ mine is in line with how
> it is supposed to work in D.

I think mine is in line with how it is supposed to work, based on the following 
facts:

1. It is how it currently is implemented.
2. It is how it works in Eiffel. The site on Contract Programming has a 
reference
to DBC in Eiffel.
3. Yours requires that all child classes duplicate the precondition of their
parents in their in-contracts. (which will then be ensured by a runtime check.).

> If you could post some D examples that would help, doing this all in my head
> is starting to hurt.

Sure, if you remember the Foo/Qux example (Foo is parent, Qux is child, method
bar(a,b), parent requires a>0 child requires else b>0)

void main(){
  auto a=new Foo, b=new Qux;
  a.bar(1,-1);//ok
  b.bar(1,-1);//ok, child works everywhere parent works
  //a.bar(-1,1);// not ok
  //b.bar(-1,-1)// not ok
  b.bar(-1,1);//ok, child works too if b>0
}


>
> I'm fairly confident a runtime test can catch the following case:

Yes but that is not correct in general (unless the behavior is changed to 
reflect
your ideas). The two contracts could be uncorrelated.
[snip]


Cheers,
-Timon

Re: D brand identity repository

[Steven Schveighoffer]

On Fri, 01 Jul 2011 12:08:17 -0400, James Fisher   
wrote:



On Thu, Jun 30, 2011 at 8:35 PM, Mafi  wrote:


This is my try.
What do you guys think about it?



So, I do think yours has merit.  The one gripe I have with it is a lack  
of

obviousness.  Compare:

New Python user: "say, why's your logo made of snakes?"
Pythoneer: "..."

New D user: "say, why's your logo got two balls in it?"
D programmer: "Well, hear me out.  Originally, the language was going to  
be
called Mars.  But then it was called D, and it's too late to change it  
back.
 Now, the two balls are Mars' two moons.  That's right, the D is Mars.   
Yes,
the D is see-through, but it was ugly to have the moons on the side, so  
you

just have to stretch to see the illusion.  And yes, the moons should be
irregular shapes, but that was ugly too."

Not sure if that gets my point across but I'm just trying to think from  
the
perspective of someone outside the community.  Which, of course, is what  
we

should be doing.


I think you are way overthinking this...

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

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

BTW, your comparison isn't correct.  I'd compare:  "Why does the python  
logo contain snakes" to "Why does the D logo contain the letter D", and  
"Why does the D logo contain balls" to "Why does the python logo look like  
a + sign".


-Steve

Re: Shortcut evaluation for hierarchy of in contracts

[Jesse Phillips]

Daniel Murphy Wrote:

> I disagree.  If the child's in condition requires something that the 
> parent's didn't, you've just tightened the precondition.
> 
> If I understand correctly, it's equivilent to:
> parent: require a is greater than 0
> child: require b is greater than 0
> 
> In this case, the parent allows more values of b than the child does, so the 
> precondition has been tightened.

No, in this case the child has allowed more values of 'a' then the parent. If 
the parent fails the child will check and say things are ok because 'b' is 
greater than 0.

Re: D brand identity repository

[%u]

related
http://www.blog.spoongraphics.co.uk/articles/a-guide-to-creating-professional-quality-logo-designs
maybe that help

Re: Shortcut evaluation for hierarchy of in contracts

[Daniel Murphy]

"Timon Gehr"  wrote in message 
news:iuksb8$15l0$1...@digitalmars.com...
> The child's contract says: If my parent's contract failed, I can still 
> satisfy the
> postcondition, if this _alternative_ precondition holds. But it does not
> necessarily have to pass on all input the parent passes on, because it 
> does not
> even get checked if the parent's precondition holds.
>
If I understand this correctly, you think the following code should be 
perfectly valid:

class A { void func(uint x) in { assert(x < 10); } body {} }
class B : A { void func(uint x) in { assert(x == 50); } body {} }

If A.func can be called with any value 0..10, why is it legal to override it 
with a function that can't accept these values?  Can you give an example 
where accepting input that is not a superset of the overriden function's 
possible input is valid? 

Re: Shortcut evaluation for hierarchy of in contracts

[Daniel Murphy]

"Timon Gehr"  wrote in message 
news:iukptu$10nq$1...@digitalmars.com...
> Daniel Murphy wrote:
>> "Timon Gehr"  wrote in message
>> news:iukoge$u82$1...@digitalmars.com...
>>> How would you catch it? I am sure it cannot be caught trivially:
>>>
>>> There are 4 possibilities:
>>> 1. Both parent and child contract would pass.
>>> 2. Parent passes, child would fail.
>>> 3. Parent fails, child passes.
>>> 4. Parent fails, child fails.
>>>
>> In case 2, the contract is invalid.
>>
>> In reality, the overriding graph forms a tree, and the contract is 
>> invalid
>> if any precondition passes if its parent's precondition fails. (the root
>> being the most derived function)
>
> That is case 3. And it is perfectly valid.
>

Sorry for the mixin of terms, I meant parent in the tree, which is the 
opposite direction to parent in inheritance.

>>
>> It is definately possible to implement runtime checking to enforce this.
>
> My first post on the subject features an example where case 2 can occur 
> and be
> valid. Have a look at it please.
>

I disagree.  If the child's in condition requires something that the 
parent's didn't, you've just tightened the precondition.

If I understand correctly, it's equivilent to:
parent: require a is greater than 0
child: require b is greater than 0

In this case, the parent allows more values of b than the child does, so the 
precondition has been tightened.

> In general:
> The precondition of the parent is:
>
> pass(in_parent)
>
> And the precondition of the child is:
>
> pass(in_parent) || pass(in_child)
>
> Trivially, the precondition of the child is always fulfilled when the 
> precondition
> of the parent is fulfilled.
>
> What you'd want to catch is iE:
>
> pass(in_parent) = a<=10
> pass(in_child) = a<=5
>
> Giving:
> precondition of parent: a<=10
> precondition of child: a<=10 || a<=5
>
> The proposed runtime check is ineffective here, as well as completely 
> redundant in
> the general case.
>
> Again: in contract of child != precondition of child
>

Ok, I doubt I used the right terms everywhere.
Reading your other post, I'm starting to think we just have different ideas 
of how contract inheritance should work.  I _think_ mine is in line with how 
it is supposed to work in D.
If you could post some D examples that would help, doing this all in my head 
is starting to hurt.

I'm fairly confident a runtime test can catch the following case:


class A
{
void func(int a)
in { assert(a < 10); }
body {}
}

class B : A
{
void func(int a)
in { assert(a < 5); }
body {}
}

void main()
{
A x = new B();

x.func(7);
} 

Re: D brand identity repository

[Nick Sabalausky]

"James Fisher"  wrote in message 
news:mailman.1364.1309536134.14074.digitalmar...@puremagic.com...
>A couple of things to keep in mind:
>
> I see every suggestion so far, including mine, uses letterplay, but a logo
> does not *have* to do this.  Note that Python's logo is not the word
> "python" made out of snakes, for example.  I see a lot of ameteur-looking
> logos around that seem to think that forcing a letter or word into a shape
> is the only way to do it.  The end result is, well, it looks forced, and
> that's bad.  I'm not advocating discarding the "D" route, but it's 
> something
> to keep in mind.  This certainly opens up possibilities for simplicity.
> There are many logos out there consisting of a simple graphic and some
> well-set text, and they look classy.  For example, we could run with the
> Mars theme, and *just* have a well-done stylized image of Mars.  Example:
> https://github.com/eegg/d-brand/raw/master/d-logo-11.png.
>
> Second thing: scalability of the image.  The logo should scale well down 
> to
> a 16x16px icon:
> https://github.com/eegg/d-brand/raw/master/d-logo-12-icon.png (this, for
> example, does not).
>
>

Certainly good points. Although since the name of the language is a letter, 
I think a letter-based logo makes a lot of sense in this case.

Re: Shortcut evaluation for hierarchy of in contracts

[Simen Kjaeraas]

On Fri, 01 Jul 2011 18:24:08 +0200, Timon Gehr  wrote:

The child's contract says: If my parent's contract failed, I can still  
satisfy the

postcondition, if this _alternative_ precondition holds. But it does not
necessarily have to pass on all input the parent passes on, because it  
does not

even get checked if the parent's precondition holds.

If you add such a check, the child's in-contract will have to carefully  
duplicate
the parent's precondition in order not to provoke a nonsensical  
runtime-error.
Adding such a check would make D's contracts unusable in anything but  
the most

trivial cases.

(Analogously, the child's 'out'-contract does not have to re-check the  
parent's

postcondition.)

'Capiche?' ;)


Absolutely. I was in the process of answering your other post where you
outlined this. Believe me, I'm on your side now. :p


--
  Simen

Re: Shortcut evaluation for hierarchy of in contracts

[Timon Gehr]

Simen Kjaeraas wrote:
> On Fri, 01 Jul 2011 17:18:38 +0200, Timon Gehr  wrote:
>
>>> This can be caught at runtime without a theorem prover. (And I think it
>>> should be)
>>
>> How would you catch it? I am sure it cannot be caught trivially:
>>
>> There are 4 possibilities:
>> 1. Both parent and child contract would pass.
>> 2. Parent passes, child would fail.
>> 3. Parent fails, child passes.
>> 4. Parent fails, child fails.
>>
>> The only case where any statement can be made is case 3: "Contracts are
>> certainly
>> well-formed".
>> You cannot deduce the well- or ill-formedness of the contracts from any
>> of the
>> other outcomes.
>>
>> In fact, you have to prove that case 3 is unfulfillable to catch
>> ill-formed contracts.
>
> for a deeper hierarchy, one would simply have a bool flag - 'has a contract
> passed?'. If a subsequent contract fails, the contract is in error, not the
> input to the function.
>
> Capiche?
>
> --
>Simen

All arguments given for a runtime check of this kind are the result of a
misunderstanding of contract inheritance. The 'in'-contract of an overridden
method merely extends the in-contract of the parent's method, and does not
override it. In that way, the compiler statically ensures that the precondition 
of
a child cannot possibly fail if the parent's passed. Thats the sole reason for 
the
short-circuiting behavior.

The child's contract says: If my parent's contract failed, I can still satisfy 
the
postcondition, if this _alternative_ precondition holds. But it does not
necessarily have to pass on all input the parent passes on, because it does not
even get checked if the parent's precondition holds.

If you add such a check, the child's in-contract will have to carefully 
duplicate
the parent's precondition in order not to provoke a nonsensical runtime-error.
Adding such a check would make D's contracts unusable in anything but the most
trivial cases.

(Analogously, the child's 'out'-contract does not have to re-check the parent's
postcondition.)

'Capiche?' ;)

--
   Timon

Re: D brand identity repository

[Adam D. Ruppe]

James Fisher wrote:
> For example, we could run with the
> Mars theme, and *just* have a well-done stylized image of Mars.

This made me think of Digital Mars:

http://digitalmars.com/dmlogo.gif

Re: D brand identity repository

[James Fisher]

On Thu, Jun 30, 2011 at 8:35 PM, Mafi  wrote:

> This is my try.
> What do you guys think about it?
>

So, I do think yours has merit.  The one gripe I have with it is a lack of
obviousness.  Compare:

New Python user: "say, why's your logo made of snakes?"
Pythoneer: "..."

New D user: "say, why's your logo got two balls in it?"
D programmer: "Well, hear me out.  Originally, the language was going to be
called Mars.  But then it was called D, and it's too late to change it back.
 Now, the two balls are Mars' two moons.  That's right, the D is Mars.  Yes,
the D is see-through, but it was ugly to have the moons on the side, so you
just have to stretch to see the illusion.  And yes, the moons should be
irregular shapes, but that was ugly too."

Not sure if that gets my point across but I'm just trying to think from the
perspective of someone outside the community.  Which, of course, is what we
should be doing.

Re: D brand identity repository

[James Fisher]

A couple of things to keep in mind:

I see every suggestion so far, including mine, uses letterplay, but a logo
does not *have* to do this.  Note that Python's logo is not the word
"python" made out of snakes, for example.  I see a lot of ameteur-looking
logos around that seem to think that forcing a letter or word into a shape
is the only way to do it.  The end result is, well, it looks forced, and
that's bad.  I'm not advocating discarding the "D" route, but it's something
to keep in mind.  This certainly opens up possibilities for simplicity.
 There are many logos out there consisting of a simple graphic and some
well-set text, and they look classy.  For example, we could run with the
Mars theme, and *just* have a well-done stylized image of Mars.  Example:
https://github.com/eegg/d-brand/raw/master/d-logo-11.png.

Second thing: scalability of the image.  The logo should scale well down to
a 16x16px icon:
https://github.com/eegg/d-brand/raw/master/d-logo-12-icon.png (this, for
example, does not).


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

> On Thu, 30 Jun 2011 18:58:38 -0400, Daniel Gibson 
> wrote:
>
>  Am 01.07.2011 00:44, schrieb Daniel Gibson:
>>
>>> Am 30.06.2011 19:25, schrieb James Fisher:
>>>
 On Thu, Jun 30, 2011 at 5:50 PM, Jeff Nowakowski 
 wrote:

  On 06/30/2011 12:28 PM, James Fisher wrote:
>
>
>> Something like this? https://github.com/eegg/d-**
>> brand/raw/master/d-logo-3.png<**https://github.com/eegg/d-**
>> brand/raw/master/d-logo-3.png
>> >
>>
>>
> I think having the separator is good (that first planet/moon always
> looked
> like some kind of tumorous growth on D to me). However, instead of
> taking a
> bite out of D, I think you should keep the current design where D
> eclipses
> the first circle.
>
>
 https://github.com/eegg/d-**brand/raw/master/d-logo-5.pngLike
  this?

 Note that the z-order is actually ambiguous in the current design :)


>>> I like this one best so far (probably because I really like the original
>>> logo), but the white border between the D and the bigger moon should be
>>> thinner. Maybe this moon should be a bit more to the right so it's more
>>> of a circle.
>>> Or maybe it should be bigger so part of it can be seen inside the D.
>>>
>>> (I don't like the other one with the small d very much, btw)
>>>
>>> Cheers,
>>> - Daniel
>>>
>>
>> I just modified the svg from your git accordingly, see attachement.
>>
>
> I like these, especially the ones with the planet being seen inside the D.
>  I agree the separating line works better as a thinner line.
>
> -Steve
>

Re: Why I'm hesitating to switch to D

[Lutger Blijdestijn]

Robert Clipsham wrote:

> On 29/06/2011 19:14, Walter Bright wrote:
>> On 6/29/2011 4:03 AM, Adam Richardson wrote:
>>> I'll admit that I looked through to see what I could help out with on
>>> the website, but ddoc stopped me in my tracks.
>>
>> How did it stop you?
> 
> DDoc vs Markdown:
>   * Pretty much everyone who uses github, stackoverflow, and many other
> sites knows some amount of markdown
>   * I've been using D for years and I pride myself on not knowing the
> hideous DDoc beyond "Params: Example:" etc.
>   * DDoc macros make even the simplest things ugly
> 

Sure, but it's really apples and oranges. Any such template system for 
markup is both complicated, limited and convenient at once. It has no power 
at all. DDoc is the other way around, it's a very different approach. The 
equivalent to ddoc's extensibility would be hacking the sources of a 
markdown processor to extend it. Now that's painful.

You could, for example, write everything in markdown but first put it 
through ddoc and then process it's output with some markdown tool. That way 
you write mostly simple markdown and have some extra power from the macro 
system. That's actually the approach that ddoc for D code has: very limited 
sugar for the most common cases, but with the optional power to extend it. 
The other way around should be possible too: a markdown macro which tags a 
fragment for postprocessing.

Re: Shortcut evaluation for hierarchy of in contracts

[Timon Gehr]

Disregard
`Disregard "That is case 3. And it is perfectly valid."

I had in contract and precondition mixed up there myself. sry.`

It was actually a valid remark: It is valid for a child to loosen the 
precondition.

Re: Shortcut evaluation for hierarchy of in contracts

[Timon Gehr]

Disregard "That is case 3. And it is perfectly valid."

I had in contract and precondition mixed up there myself. sry.

Re: Shortcut evaluation for hierarchy of in contracts

[Timon Gehr]

Daniel Murphy wrote:
> "Timon Gehr"  wrote in message
> news:iukoge$u82$1...@digitalmars.com...
>> How would you catch it? I am sure it cannot be caught trivially:
>>
>> There are 4 possibilities:
>> 1. Both parent and child contract would pass.
>> 2. Parent passes, child would fail.
>> 3. Parent fails, child passes.
>> 4. Parent fails, child fails.
>>
> In case 2, the contract is invalid.
>
> In reality, the overriding graph forms a tree, and the contract is invalid
> if any precondition passes if its parent's precondition fails. (the root
> being the most derived function)

That is case 3. And it is perfectly valid.

>
> It is definately possible to implement runtime checking to enforce this.

My first post on the subject features an example where case 2 can occur and be
valid. Have a look at it please.

In general:
The precondition of the parent is:

pass(in_parent)

And the precondition of the child is:

pass(in_parent) || pass(in_child)

Trivially, the precondition of the child is always fulfilled when the 
precondition
of the parent is fulfilled.

What you'd want to catch is iE:

pass(in_parent) = a<=10
pass(in_child) = a<=5

Giving:
precondition of parent: a<=10
precondition of child: a<=10 || a<=5

The proposed runtime check is ineffective here, as well as completely redundant 
in
the general case.

Again: in contract of child != precondition of child


Cheers,
-Timon

Re: Shortcut evaluation for hierarchy of in contracts

[Simen Kjaeraas]

On Fri, 01 Jul 2011 17:18:38 +0200, Timon Gehr  wrote:


This can be caught at runtime without a theorem prover. (And I think it
should be)


How would you catch it? I am sure it cannot be caught trivially:

There are 4 possibilities:
1. Both parent and child contract would pass.
2. Parent passes, child would fail.
3. Parent fails, child passes.
4. Parent fails, child fails.

The only case where any statement can be made is case 3: "Contracts are  
certainly

well-formed".
You cannot deduce the well- or ill-formedness of the contracts from any  
of the

other outcomes.

In fact, you have to prove that case 3 is unfulfillable to catch  
ill-formed contracts.


for a deeper hierarchy, one would simply have a bool flag - 'has a contract
passed?'. If a subsequent contract fails, the contract is in error, not the
input to the function.

Capiche?

--
  Simen

Re: Shortcut evaluation for hierarchy of in contracts

[Daniel Murphy]

"Timon Gehr"  wrote in message 
news:iukoge$u82$1...@digitalmars.com...
> How would you catch it? I am sure it cannot be caught trivially:
>
> There are 4 possibilities:
> 1. Both parent and child contract would pass.
> 2. Parent passes, child would fail.
> 3. Parent fails, child passes.
> 4. Parent fails, child fails.
>
In case 2, the contract is invalid.

In reality, the overriding graph forms a tree, and the contract is invalid 
if any precondition passes if its parent's precondition fails. (the root 
being the most derived function)

It is definately possible to implement runtime checking to enforce this. 

Re: thread.d "Unable to load thread context"

[Sean Kelly]

On Jul 1, 2011, at 7:46 AM, Benjamin Thaut wrote:

> Am 01.07.2011 15:00, schrieb Sean Kelly:
>> Then something else must be going on. This is Windows XP/7 and not WINE, 
>> right?
> 
> Yes this is has been tested on 4 different Windows 7 machines.
> 
> My game is cross platform, and on Linux it runs absolutly stable. (Without 
> wine, directly on linux)
> 
> If you want I can provide you with the sourcecode and everything else needed, 
> or I can test proposed fixes if you have any.

Can you run it in a debugger and send me stack traces of all the threads when 
GetThreadContext fails?

Re: Shortcut evaluation for hierarchy of in contracts

[David Nadlinger]

On 7/1/11 5:18 PM, Timon Gehr wrote:

There are 4 possibilities:
1. Both parent and child contract would pass.
2. Parent passes, child would fail.
3. Parent fails, child passes.
4. Parent fails, child fails.

The only case where any statement can be made is case 3: "Contracts are 
certainly
well-formed".
You cannot deduce the well- or ill-formedness of the contracts from any of the
other outcomes.


In my opinion, one *is* able to declare the child contract invalid in 
case 2 – if the parent passes but the child fails, it certainly violates 
the »loosening« property of in contract inheritance. If you don't think 
so, could you please explain your doubts in more detail?


David

Re: Shortcut evaluation for hierarchy of in contracts

[Timon Gehr]

Daniel Murphy wrote:
> I don't disagree that tightening contracts for derived functions is a bad
> idea.
> I didn't mean the contract should fail, I meant that the program should fail
> with an error that the contract is invalid.
>
> "Timon Gehr"  wrote in message
> news:iuklvm$pks$1...@digitalmars.com...
>> Now, sure, if the parents contract is
>>
>> in{assert(a<=10);}
>>
>> and the child's contract is
>>
>> in{assert(a<=5);}
>>
>> then that is almost certainly an error because the child's contract fails
>> to
>> loosen any restrictions.
>> But to catch this in the general case, the compiler would have to
>> incorporate a
>> theorem prover.
>> (And validity of D code would start to depend on the quality of the
>> theorem prover
>> of the respective D compiler ;))
>
> This can be caught at runtime without a theorem prover. (And I think it
> should be)

How would you catch it? I am sure it cannot be caught trivially:

There are 4 possibilities:
1. Both parent and child contract would pass.
2. Parent passes, child would fail.
3. Parent fails, child passes.
4. Parent fails, child fails.

The only case where any statement can be made is case 3: "Contracts are 
certainly
well-formed".
You cannot deduce the well- or ill-formedness of the contracts from any of the
other outcomes.

In fact, you have to prove that case 3 is unfulfillable to catch ill-formed 
contracts.

Cheers,
-Timon

Re: Shortcut evaluation for hierarchy of in contracts

[Daniel Murphy]

I don't disagree that tightening contracts for derived functions is a bad 
idea.
I didn't mean the contract should fail, I meant that the program should fail 
with an error that the contract is invalid.

"Timon Gehr"  wrote in message 
news:iuklvm$pks$1...@digitalmars.com...
> Now, sure, if the parents contract is
>
> in{assert(a<=10);}
>
> and the child's contract is
>
> in{assert(a<=5);}
>
> then that is almost certainly an error because the child's contract fails 
> to
> loosen any restrictions.
> But to catch this in the general case, the compiler would have to 
> incorporate a
> theorem prover.
> (And validity of D code would start to depend on the quality of the 
> theorem prover
> of the respective D compiler ;))

This can be caught at runtime without a theorem prover. (And I think it 
should be) 

Re: thread.d "Unable to load thread context"

[Benjamin Thaut]

Am 01.07.2011 15:00, schrieb Sean Kelly:

Then something else must be going on. This is Windows XP/7 and not WINE, right?

Sent from my iPhone


Yes this is has been tested on 4 different Windows 7 machines.

My game is cross platform, and on Linux it runs absolutly stable. 
(Without wine, directly on linux)


If you want I can provide you with the sourcecode and everything else 
needed, or I can test proposed fixes if you have any.


--
Kind Regards
Benjamin Thaut

Re: Shortcut evaluation for hierarchy of in contracts

[Timon Gehr]

Daniel Murphy wrote:
> "Walter Bright"  wrote in message
> news:iuju03$27ip$1...@digitalmars.com...
>> The 'in' contract must pass at least one of the 'in' contracts of its
>> inheritance hierarchy.
>> Derived functions "loosen" the requirements for input.
>
> This might be the recommended way to do it, but this is not enforced by the
> compiler, just assumed.
>
> To enforce this, the compiler should give an error if a base function's
> precondition passes but a derived precondition does not.
>
> The requirement is not really that any 'in' contract passing is good enough,
> it's just assumed that all preconditions on inherited functions will pass if
> the base contract does.

Actually that is not true. One passing contract is enough. The current (and
correct) behavior enforces that when the parents contract passes, the child's
contract passes too.

If both had to pass, a child class could actually make contracts more 
restrictive.
It is this what we want to avoid, right?

The mistake is to assume, that the in contract of the child classes method
consists of what is written there only.
But arguably that is a problem with the language. Compare CP in D to Bertrand
Meyer's DBC in Eiffel:

//D
class Foo{
  void bar(int a, int)
  in{assert(a>0);} // require that a>0
  out(r){assert r>0;}
  body{
return a;
  }
}

class Qux : Foo{
  override void bar(int a,int b)loosen
  in{assert(b>0);} //'if parents contract fails, I can still produce sensible
behavior if b>0 holds'
  body{
return a>0?a:b;
  }
}

--Eiffel
class Foo
feature
  bar(a,b:INTEGER)
require
  a_positive: a>0
do
  Result:=a
ensure
  result_positive: Result>0
end
end

class Qux
inherit
  Foo
redefine bar end
feature
  bar(a,b:INTEGER)
require else-- important!
  b_positive: b>0
do
  if a>0 then Result:=a
  else Result:=b
end
end

As you can see, in Eiffel, contract extension has a different syntax than 
contract
definition. ('require else' vs. require) In D the syntax is identical, even 
though
the two things done are quite different. What effectively is done depends on
whether or not the override keyword is present. I assume it is this that has led
to the misunderstanding.

Now, sure, if the parents contract is

in{assert(a<=10);}

and the child's contract is

in{assert(a<=5);}

then that is almost certainly an error because the child's contract fails to
loosen any restrictions.
But to catch this in the general case, the compiler would have to incorporate a
theorem prover.
(And validity of D code would start to depend on the quality of the theorem 
prover
of the respective D compiler ;))

Cheers,
-Timon

Re: Shortcut evaluation for hierarchy of in contracts

[Daniel Murphy]

"Walter Bright"  wrote in message 
news:iuju03$27ip$1...@digitalmars.com...
> The 'in' contract must pass at least one of the 'in' contracts of its 
> inheritance hierarchy.
> Derived functions "loosen" the requirements for input.

This might be the recommended way to do it, but this is not enforced by the 
compiler, just assumed.

To enforce this, the compiler should give an error if a base function's 
precondition passes but a derived precondition does not.

The requirement is not really that any 'in' contract passing is good enough, 
it's just assumed that all preconditions on inherited functions will pass if 
the base contract does. 

Re: thread.d "Unable to load thread context"

[Sean Kelly]

Then something else must be going on. This is Windows XP/7 and not WINE, right?

Sent from my iPhone

On Jul 1, 2011, at 2:19 AM, Benjamin Thaut  wrote:

> Am 01.07.2011 03:51, schrieb Sean Kelly:
>> This is the only one I can think of, and it was added based on a suggestion 
>> following a report of a similar bug elsewhere. It sounds like in some weird 
>> circumstances, SuspendThread may return before the thread is suspended. 
>> There's no way to determine this and I'd call it a kernel bug if true, and 
>> the only real option is to spin on GetThreadContext for a bit before giving 
>> up and halting the app.
>> 
>> Sent from my iPhone
>> 
>> On Jun 30, 2011, at 4:31 PM, "Eric Poggel 
>> (JoeCoder)"  wrote:
>> 
>>> On 6/30/2011 3:05 PM, Sean Kelly wrote:
 On Jun 30, 2011, at 2:40 AM, Benjamin Thaut wrote:
 
> Am 30.06.2011 06:45, schrieb Sean Kelly:
>> On Jun 29, 2011, at 10:00 AM, Benjamin Thaut wrote:
>>> If I manually merge your fix into the thread.d of the 2.053 runtime 
>>> (change m to __gshared in slock) the issue still exsits. After a while 
>>> the game will stop with "unable to load thread context".
>> 
>> Just for kicks, rewrite the GetThreadContext call as this and see if it 
>> works in 2.053:
>> 
>> for( int i = 0; !GetThreadContext( t.m_hndl,&context ); i++ )
>> {
>> if( i>99 )
>> throw new ThreadException( "Unable to load thread 
>> context" );
>> Thread.yield();
>> }
>> 
> 
> The for loop seems to have fixed the issue, at least I'm not able to 
> reproduce it easily any more. I'm going to be able to tell you tomorrow 
> if the issue is fixed completely or not.
 
 Cool.  I've applied the change to druntime.
 
> Does any access to the GC cause a Exception to be thrown? I mean even a 
> removeRange call?
 
 malloc, realloc, extend, reserve, addRoot, and addRange.  I think that's 
 it.
>>> 
>>> This makes me wonder how many other such hacks like this are in DRuntime.  
>>> If this problem happens once every 30 minutes, then I suppose this 
>>> decreases it to once every 30^100 minutes (which is older than the 
>>> universe).
> 
> The loop unfortunately didn't fix the problem. It just became less frequent. 
> I even tried adding additional Sleep time to the loop without success.
> 
> -- 
> Kind Regards
> Benjamin Thaut

Re: D brand identity repository

[Steven Schveighoffer]

On Thu, 30 Jun 2011 18:58:38 -0400, Daniel Gibson   
wrote:



Am 01.07.2011 00:44, schrieb Daniel Gibson:

Am 30.06.2011 19:25, schrieb James Fisher:
On Thu, Jun 30, 2011 at 5:50 PM, Jeff Nowakowski   
wrote:



On 06/30/2011 12:28 PM, James Fisher wrote:



Something like this? https://github.com/eegg/d-**
brand/raw/master/d-logo-3.png



I think having the separator is good (that first planet/moon always  
looked
like some kind of tumorous growth on D to me). However, instead of  
taking a
bite out of D, I think you should keep the current design where D  
eclipses

the first circle.



https://github.com/eegg/d-brand/raw/master/d-logo-5.png Like this?

Note that the z-order is actually ambiguous in the current design :)



I like this one best so far (probably because I really like the original
logo), but the white border between the D and the bigger moon should be
thinner. Maybe this moon should be a bit more to the right so it's more
of a circle.
Or maybe it should be bigger so part of it can be seen inside the D.

(I don't like the other one with the small d very much, btw)

Cheers,
- Daniel


I just modified the svg from your git accordingly, see attachement.


I like these, especially the ones with the planet being seen inside the  
D.  I agree the separating line works better as a thinner line.


-Steve

Re: D brand identity repository

[Steven Schveighoffer]

On Thu, 30 Jun 2011 17:41:30 -0400, bearophile   
wrote:



Tyro[a.c.edwards]:


Now there's an Idea. Simple yet elegant... no boobs and retains the
historical reference to Mars and her two moons. I like it. I'll even
take the italics.

++ Vote

Oh wait, I only have one vote.


But Deimos is not so round :-)
http://en.wikipedia.org/wiki/Deimos_%28moon%29


I found this amusing from the wikipedia article:

"Deimos, like Mars' other moon Phobos, has spectra, albedos and densities  
similar to those of a C- or D-type asteroid."


:)

-Steve

Re: Why I'm hesitating to switch to D

[simendsjo]

On 01.07.2011 11:33, Jacob Carlborg wrote:

On 2011-07-01 02:29, simendsjo wrote:

Looks ergonomically "correct", but pretty massive. I've considered
TypeMatrix (http://typematrix.com/) in the past, but I think it's a bit
expensive.


I've never understood how keyboards with keys sitting almost vertical
can be ergonomically correct. It's like pressing keys sitting on a wall.



I know. It looks very wrong in this regard. But I like the placement of 
other keys like enter and backspace.

Re: D brand identity repository

[Jacob Carlborg]

On 2011-07-01 04:06, Adam Richardson wrote

Hi,

Just for comparisons, I've added some more variations, just playing
around with the text that might be in proximity (hash tag, couple
variations including "programming language".)

http://envisionic.com/images/d-logo-draft-2.png

Adam


I think it looks best with a sans-serif font.

--
/Jacob Carlborg

Re: Why I'm hesitating to switch to D

[Jacob Carlborg]

On 2011-07-01 02:29, simendsjo wrote:

Looks ergonomically "correct", but pretty massive. I've considered
TypeMatrix (http://typematrix.com/) in the past, but I think it's a bit
expensive.


I've never understood how keyboards with keys sitting almost vertical 
can be ergonomically correct. It's like pressing keys sitting on a wall.


--
/Jacob Carlborg

Faster accurate printing of floating-point numbers

[Daniel Gibson]

Hi,

dunno if D maybe already uses something like that, but I just stumbled
upon this article and thought it may be of interest:
http://www.serpentine.com/blog/2011/06/29/here-be-dragons-advances-in-problems-you-didnt-even-know-you-had/

The article claims that the discussed algorithm is about 5 times faster
than what the GNU libc uses in printf.

Cheers,
- Daniel

Re: thread.d "Unable to load thread context"

[Benjamin Thaut]

Am 01.07.2011 03:51, schrieb Sean Kelly:

This is the only one I can think of, and it was added based on a suggestion 
following a report of a similar bug elsewhere. It sounds like in some weird 
circumstances, SuspendThread may return before the thread is suspended. There's 
no way to determine this and I'd call it a kernel bug if true, and the only 
real option is to spin on GetThreadContext for a bit before giving up and 
halting the app.

Sent from my iPhone

On Jun 30, 2011, at 4:31 PM, "Eric Poggel (JoeCoder)"  
wrote:


On 6/30/2011 3:05 PM, Sean Kelly wrote:

On Jun 30, 2011, at 2:40 AM, Benjamin Thaut wrote:


Am 30.06.2011 06:45, schrieb Sean Kelly:

On Jun 29, 2011, at 10:00 AM, Benjamin Thaut wrote:

If I manually merge your fix into the thread.d of the 2.053 runtime (change m to 
__gshared in slock) the issue still exsits. After a while the game will stop with 
"unable to load thread context".


Just for kicks, rewrite the GetThreadContext call as this and see if it works 
in 2.053:

 for( int i = 0; !GetThreadContext( t.m_hndl,&context ); i++ )
 {
 if( i>99 )
 throw new ThreadException( "Unable to load thread context" 
);
 Thread.yield();
 }



The for loop seems to have fixed the issue, at least I'm not able to reproduce 
it easily any more. I'm going to be able to tell you tomorrow if the issue is 
fixed completely or not.


Cool.  I've applied the change to druntime.


Does any access to the GC cause a Exception to be thrown? I mean even a 
removeRange call?


malloc, realloc, extend, reserve, addRoot, and addRange.  I think that's it.


This makes me wonder how many other such hacks like this are in DRuntime.  If 
this problem happens once every 30 minutes, then I suppose this decreases it to 
once every 30^100 minutes (which is older than the universe).


The loop unfortunately didn't fix the problem. It just became less 
frequent. I even tried adding additional Sleep time to the loop without 
success.


--
Kind Regards
Benjamin Thaut

Re: Why I'm hesitating to switch to D

[Jacob Carlborg]

On 2011-07-01 02:19, Jonathan M Davis wrote:

I switched to dvorak _and_ got one of these: http://www.kinesis-
ergo.com/advantage.htm

No one is going to be using my computer with my keyboard. Though honestly, as
much as I like dvorak, I wouldn't advise that anyone switch to it. Too many
programs assume qwerty, so all of their shortcuts are designed for it. Stuff
like the shortcuts for cut, copy, and paste are on completely different places
on the keyboard and don't work as well (only cut can be done with just your
left hand). I had to completely remap vim to be able to use it. Other programs
need their keys or shortcuts remapped to work very well. It just causes
problems for stuff that assumes qwerty. So, it's likely more pain than its
worth. My keyboard is awesome regardless of whether you use qwerty or dvork
though. I can actually type numbers on it without looking, which I could never
do on a normal keyboard, because the keys aren't vertically aligned on a
normal keyboard. It's expensive, but I'm quite happy that I bought it.

- Jonathan M Davis



Using this keyboard: http://www.typematrix.com with the dvorak layout 
you can use other keys then ctrl+x/c/v for cut, copy and paste. If you 
look in the store, and choose "Skin Only" and then dvorka you can see it 
has keys for cut, copy and paste in similar places where ctrl+x/c/v 
would be on a normal keyboard.


--
/Jacob Carlborg

Re: D brand identity repository

[Mafi]

Am 01.07.2011 00:39, schrieb Chris Molozian:

It's a great logo Mafi, is it possible to try it without the italics and
see what that looks like?


Here are a non-italic and it's corresponding as-path version.
I think I like the italic version a little bit more.

Mafi
<><>

Re: Shortcut evaluation for hierarchy of in contracts

[Jens Mueller]

Walter Bright wrote:
> On 6/30/2011 3:42 AM, Jens Mueller wrote:
> >The shortcut evaluation is specified in TDPL. That's why I assume the
> >behavior is intended.
> 
> The behavior is both intended and crucial to the notion of contract 
> inheritance.
> 
> The 'in' contract must pass at least one of the 'in' contracts of
> its inheritance hierarchy.
> Derived functions "loosen" the requirements for input.

Yes. But the problem with passing only one of the in contracts is that
it is error-prone because it *assumes* that for in contracts the
requirements are widened. But what if the programmer fails at loosening
a derived in contract, i.e. he restricted it. In the current setting the
programmer won't know that he did an error. And with deep inheritance
hierarchies it gets more complicated to have all the contracts of super
classes in mind.
Why not check all in contracts to make sure that they follow the
loosening rule? Why not enforce the loosing rule?

Jens

Re: Shortcut evaluation for hierarchy of in contracts

[Walter Bright]

On 6/30/2011 3:42 AM, Jens Mueller wrote:

The shortcut evaluation is specified in TDPL. That's why I assume the
behavior is intended.


The behavior is both intended and crucial to the notion of contract inheritance.

The 'in' contract must pass at least one of the 'in' contracts of its 
inheritance hierarchy.

Derived functions "loosen" the requirements for input.

The 'out' contract must pass all of the 'out' contracts.
Derived functions "tighten" the requirements for output.