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,
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);
stat
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
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)
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); }
>>> bod
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
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 a
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 com
"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 contr
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 doub
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 i
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
"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);/
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:
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, w
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 possibiliti
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 l
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,
related
http://www.blog.spoongraphics.co.uk/articles/a-guide-to-creating-professional-quality-logo-designs
maybe that help
"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, b
"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
"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" m
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
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 c
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
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
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
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:
> * Pr
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.
Disregard "That is case 3. And it is perfectly valid."
I had in contract and precondition mixed up there myself. sry.
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 f
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,
"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. Paren
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 ru
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-f
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
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 par
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, directl
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 d
"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 enforce
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
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
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 i
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 ve
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 l
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 l
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 ti
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 t
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
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
<><>
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 o
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
inherita
52 matches
Mail list logo
