Stewart Gordon wrote:
> I'm still none the wiser about why it absolutely has to be done like this instead of the simpler solution I proposed years ago.

Can you refresh my memory?

(The nested function approach is fairly simple in terms of lines of code to implement.)

Walter Bright wrote:
> Stewart Gordon wrote:
>> I'm still none the wiser about why it absolutely has to be done like this instead of the simpler solution I proposed years ago.
> 
> Can you refresh my memory?

Seems straightforward to find to me, but here it is:

http://www.digitalmars.com/d/archives/digitalmars/D/31595.html

> (The nested function approach is fairly simple in terms of lines of code to implement.)

I can imagine how it works now.  Essentially it's a function that can act as a nested function to the function for which it is originally defined or any override of it, which works since a nested function is really just a function with a pointer to the outer function's stack frame as a parameter.  Correct?

BTW I just rediscovered this old thread

http://www.digitalmars.com/d/archives/digitalmars/D/9775.html

which is making me think we probably ought to enable contracts on bodyless functions some time.

Stewart.

Walter Bright Wrote:

> It's outlined in the code comments, but it's implemented by making the contract code a nested function. The overriding function calls those nested functions of the overridden function(s). In order for this to work successfully, the 'this' pointer and the stack parameters must wind up in the same relative position on the stack.

'this' pointer could be passed as a regular argument just like stack pointer.

Leandro Lucarella wrote:
> Thanks for finally taking this way, Walter =)
> 
> http://www.dsource.org/projects/dmd/timeline

Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for "Nightly" builds and maybe even post the results to the D newsgroups/IRC channels.

If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you.

Robert Clipsham wrote:
> Leandro Lucarella wrote:
>> Thanks for finally taking this way, Walter =)
>>
>> http://www.dsource.org/projects/dmd/timeline
> 
> Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for "Nightly" builds and maybe even post the results to the D newsgroups/IRC channels.
> 
> If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you.

The problem is if some package fails, then I have a large debugging problem trying to figure out unfamiliar code.

Hello Walter,

>> I can set it
>> up to automatically build dmd after a commit, and run dstress/build
>> popular projects and libraries
> 
> The problem is if some package fails, then I have a large debugging
> problem trying to figure out unfamiliar code.
> 

Or it could just inform the owner of the lib and they can cut out a test cases or even do most of the detective work for you.

Robert Clipsham wrote:
> Leandro Lucarella wrote:
>> Thanks for finally taking this way, Walter =)
>>
>> http://www.dsource.org/projects/dmd/timeline
> 
> Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for "Nightly" builds and maybe even post the results to the D newsgroups/IRC channels.
> 
> If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you.

I think that'd be fantastic. It'd be helpful if you could at least get dstress to run after the main releases. The dstress test page from LDC doesn't seem to operate any more.

http://www.incasoftware.de/~kamm/ldc/tests/index.html

I'd really like to see the results for the latest DMD, almost all of the  "ERROR" (segfault/ICE) bugs should be fixed now.

Walter doesn't necessarily ever have to look at it, but it'd be good as a pre-release check.

There are quite a few incorrect dstress tests. I've been making tickets for them as I find them.

BCS wrote:
> Hello Walter,
> 
>>> I can set it
>>> up to automatically build dmd after a commit, and run dstress/build
>>> popular projects and libraries
>>
>> The problem is if some package fails, then I have a large debugging
>> problem trying to figure out unfamiliar code.
>>
> 
> Or it could just inform the owner of the lib and they can cut out a test cases or even do most of the detective work for you.

Then please go ahead and set it up.

Don wrote:
> I think that'd be fantastic. It'd be helpful if you could at least get dstress to run after the main releases. The dstress test page from LDC doesn't seem to operate any more.
> 
> http://www.incasoftware.de/~kamm/ldc/tests/index.html

This page gets updated manually by Christian as he feels fit. For more up to date pages, see:

http://ldc.octarineparrot.com/x86-32/web/
http://ldc.octarineparrot.com/x86-64/web/

For x86-32 and x86-64 respectively (these aren't completely automated yet, they require me to run a command to generate them every now and again... I'll sort this out when I get it set up for dmd). They still compare to dmd 1.045 as ldc still uses the 1.045 front end (I believe there were some regressions from 1.046+, not sure on the current status of this).

> I'd really like to see the results for the latest DMD, almost all of the  "ERROR" (segfault/ICE) bugs should be fixed now.

This will get run when I set it up :)

> Walter doesn't necessarily ever have to look at it, but it'd be good as a pre-release check.

Agreed.

> There are quite a few incorrect dstress tests. I've been making tickets for them as I find them.

I believe Christian is the maintainer for the dstress project on dsource, he should be able to give you commit access if you have patches.

Walter Bright wrote:
> Then please go ahead and set it up.

What exactly would you like setting up? Currently I'm thinking:

* Automated builds of dmd 1 and 2
* Automated builds of druntime, phobos and tango
* Automated DStress runs
* Automated dmd test suite runs (if you're willing to provide me access to the test suite)
* Automated builds of more popular projects from dsource (with permission from the maintainers obviously)

Is there anything else you want?

I also need to know how you would like results to be reported. Would you like them to sit on a web page with an RSS feed, email the results to a specified list of email addresses, post to the nextgroups, post to IRC?