Testing lazy ranges in post-conditions

If a function returns a lazy range, I can't verify its 
correctness in the function post-condition because inside the 
post-condition such range is const.

An example of the problem:

import std.range, std.algorithm;

auto foo()
out(result) {
     assert(result.all!(x => x < 10));
} body {
     return iota(5);
}

void main() {}

This limits the usefulness of post-conditions in my code. Do you 
have ideas to solve this problem?

Bye,
bearophile

Re: GSOC Summer 2015 - Second call for Proposals

On Saturday, 22 November 2014 at 15:27:00 UTC, Russel Winder via 
Digitalmars-d wrote:
> On Wed, 2014-11-05 at 03:54 +0000, Craig Dillabaugh via 
> Digitalmars-d
> wrote:
> […]
>
> Apologies for being late to reply. Long story, no sensible 
> tl;dr.
>
> […]
>> Russel Winder         Phobos/QML: std.parallelism, 
>> std.benchmark
> […]
>
> Not sure about Phobos here but D really does need to be able to 
> connect
> to QML. This proposal is therefore to create a way of 
> communicating
> between D codes and QML engines via signals and slots. The 
> model here is
> the Go/QML system. It works very well, but isn't D.
>
> std.parallelism needs a review and some benchmarking, prior to 
> making
> improvements: some of the things David put into it are not as 
> performant
> as it would be nice for them to be. As part of this is would be 
> good to
> have a standard benchmarking framework, hence the idea of 
(Continue reading)

Re: Comparing Parallelization in HPC with D, Chapel, and Go

Yes, I'd be curious to see the code.  I also suspect that the 
functionality in core may not be sufficiently advertised.  At one 
point he mentions using yieldForce to simulate a barrier, which 
suggests he wasn't aware of core.sync.barrier.

via Digitalmars-d | 22 Nov 16:16 2014

lazy void vs int delegate() as overloads - bug or illegal use of overloading?

Hi,
I'm trying to do a version of this:

	import std.stdio;

	void main()
	{
		execute(writeln("Hello, world"));
		execute({return 5;});
	}

	void execute(int delegate() f)
	{
		writeln("f is delegate, returning ", f());
	}

	void execute(lazy void f)
	{
		writeln("f is lazy void");
		f();
	}

which causes the compiler to respond: Error: void does not have a 
default initializer.

I've narrowed it down to the fact that the function "execute" is 
overloaded - if I give them different names, it works fine.

My question is, is this a bug or is it an intentionally disabled 
way of overloading the functions?
(Continue reading)

Re: 'int' is enough for 'length' to migrate code from x86 to x64

On 11/21/14 8:57 AM, ketmar via Digitalmars-d wrote:
> On Fri, 21 Nov 2014 08:31:13 -0800
> Andrei Alexandrescu via Digitalmars-d <digitalmars-d <at> puremagic.com>
> wrote:
>
>> Would you agree that that would break a substantial amount of correct D
>> code? -- Andrei
> i don't think that code with possible int wrapping and `auto` is
> correct, so the answer is "no". bad code must be made bad.

I think you misunderstood the question. -- Andrei

How to switch context from fiber to original fiber?

So I've been using an event range rather than an event loop or 
event/listener system; because I realized I could process events 
more effectively using a recursive descent parser on them.  So I 
made this class to strip the events into different ranges and 
send them to different parsers:

auto demultiplex(alias attrFunc, string functional, Range)(Range 
r)
{
	alias attr = std.functional.unaryFun!(attrFunc);
	alias T    = ElementType!(Range);
	
	struct SlaveRange {
	private T**               _front;
	private Fiber _fiber;		
		this(T ** it) {	
			_front = it;
			_fiber = Fiber.getThis();
		}
		
		 <at> property bool empty() const { return *_front is null; }
		 <at> property T    front() const { return *(*_front); }
		          void popFront()    { _fiber.call(); }
	}
		
	struct MasterRange {
		private SlaveRange        _slave;
		private Range             _input;
		private T                 _cur;
		private T               * _front;
(Continue reading)

Re: 'int' is enough for 'length' to migrate code from x86 to x64

Am Fri, 21 Nov 2014 11:41:55 -0800
schrieb "H. S. Teoh via Digitalmars-d"
<digitalmars-d <at> puremagic.com>:

> On Fri, Nov 21, 2014 at 10:57:44AM -0800, Walter Bright via Digitalmars-d wrote:
> > On 11/21/2014 10:05 AM, ketmar via Digitalmars-d wrote:
> > >why do you believe that i'm not aware of overflows and don't checking
> > >for that? i'm used to think about overflows and do overflow checking
> > >in production code since my Z80 days. and i don't believe that
> > >"infrequent bug" is better than "frequent bug". both are equally bad.
> > 
> > 
> > Having coded with 16 bit computers for decades, one gets used to
> > thinking about and dealing with overflows :-)
> 
> I used to write 8-bit assembly code on the 6502 (yeah I'm so dating
> myself), where overflows and underflows happen ALL THE TIME. :-) In
> fact, they happen so much, that I learned to embrace modulo arithmetic
> instead of fearing it. I would take advantage of value wrapping to shave
> off a few cycles here and a few cycles there -- they do add up, given
> that the CPU only ran at a meager 1MHz, so every little bit counts.
> 
> Then in the 16-bit days, I wrote a sliding-window buffer using a 64kB
> buffer where the wraparound of the 16-bit index variable was a feature
> rather than a bug. :-)  Basically, once it reaches within a certain
> distance from the end of the window, the next 32kB block of data was
> paged in from disk into the other half of the buffer, so as long as the
> operation didn't span more than 32kB each time, you can just increment
> the 16-bit index without needing to check for the end of the buffer --
> it'd automatically wrap around to the beginning where the new 32kB block
(Continue reading)

anon via Digitalmars-d | 21 Nov 22:29 2014

Comparing Parallelization in HPC with D, Chapel, and Go


https://www.academia.edu/3982638/A_Study_of_Successive_Over-relaxation_SOR_Method_Parallelization_Over_Modern_HPC_Languages

Re: 'int' is enough for 'length' to migrate code from x86 to x64

On 11/21/2014 12:09 PM, ketmar via Digitalmars-d wrote:
> On Fri, 21 Nov 2014 11:52:29 -0800
> Walter Bright via Digitalmars-d <digitalmars-d <at> puremagic.com> wrote:
>
>> So 'auto' has different type rules for expressions than anywhere else in D?
>>
>> Consider:
>>
>>       void foo(T)(T a) { ... }
>>
>>       if (x - 1) foo(x - 1);
>>       if (auto a = x - 1) foo(a);
>>
>> and now foo() is instantiated with a different type?
>>
>> I'm afraid I can't sell that to anyone :-(
> the whole thing of `auto` is to let compiler decide. i won't be
> surprised if `a` becomes 80-bit real or bigint here -- that's up to
> compiler to decide which type will be able to hold the whole range.
> `auto` for me means "i don't care what type you'll choose, just do it
> for me and don't lose any bits." this can be some kind of structure
> with overloaded operators, for example.
>

'auto' doesn't mean "break my code if I refactor out expressions into temporaries".

Re: 'int' is enough for 'length' to migrate code from x86 to x64

On 11/21/2014 11:36 AM, ketmar via Digitalmars-d wrote:
> On Fri, 21 Nov 2014 10:59:13 -0800
> Walter Bright via Digitalmars-d <digitalmars-d <at> puremagic.com> wrote:
>
>> On 11/21/2014 6:03 AM, ketmar via Digitalmars-d wrote:
>>> On Thu, 20 Nov 2014 13:28:37 -0800
>>> Walter Bright via Digitalmars-d <digitalmars-d <at> puremagic.com> wrote:
>>>
>>>> On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
>>>>> What *could* be improved, is the prevention of obvious mistakes in
>>>>> *mixing* signed and unsigned types. Right now, D allows code like the
>>>>> following with no warning:
>>>>>
>>>>> 	uint x;
>>>>> 	int y;
>>>>> 	auto z = x - y;
>>>>>
>>>>> BTW, this one is the same in essence as an actual bug that I fixed in
>>>>> druntime earlier this year, so downplaying it as a mistake people make
>>>>> 'cos they confound computer math with math math is fallacious.
>>>>
>>>> What about:
>>>>
>>>>        uint x;
>>>>        auto z = x - 1;
>>>>
>>>> ?
>>>>
>>> here z must be `long`. and for `ulong` compiler must emit error.
>>
(Continue reading)

Re: 'int' is enough for 'length' to migrate code from x86 to x64

On 11/21/2014 6:03 AM, ketmar via Digitalmars-d wrote:
> On Thu, 20 Nov 2014 13:28:37 -0800
> Walter Bright via Digitalmars-d <digitalmars-d <at> puremagic.com> wrote:
>
>> On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
>>> What *could* be improved, is the prevention of obvious mistakes in
>>> *mixing* signed and unsigned types. Right now, D allows code like the
>>> following with no warning:
>>>
>>> 	uint x;
>>> 	int y;
>>> 	auto z = x - y;
>>>
>>> BTW, this one is the same in essence as an actual bug that I fixed in
>>> druntime earlier this year, so downplaying it as a mistake people make
>>> 'cos they confound computer math with math math is fallacious.
>>
>> What about:
>>
>>       uint x;
>>       auto z = x - 1;
>>
>> ?
>>
> here z must be `long`. and for `ulong` compiler must emit error.

So, any time an integer literal appears in an unsigned expression, the type of 
the expression becomes signed?

(Continue reading)


Gmane