www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD svn and contract inheritance

reply Leandro Lucarella <llucax gmail.com> writes:
Thanks for finally taking this way, Walter =)

http://www.dsource.org/projects/dmd/timeline

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
He andáu muchos caminos, muchos caminos he andáu, Chile tiene el buen
vino y Suecia, el bacalao. Esta'o Unido tiene el hot do', Cuba tiene el
mojito, Guatemala, el cornalito y Brasil la feishoada.
Sep 27 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Thanks for finally taking this way, Walter =)


You're welcome. I hadn't done it before because I couldn't figure out a 
reasonable way of implementing it.
Sep 27 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 27 de septiembre a las 13:45 me escribiste:

 Leandro Lucarella wrote:

Thanks for finally taking this way, Walter =)


 
 You're welcome. I hadn't done it before because I couldn't figure
 out a reasonable way of implementing it.


I don't know if you are talking about DMD being in a public repo, the
contract inheritance or both. But anyway, I'm glad you could finally do
both =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
JUNTAN FIRMAS Y HUELLAS POR EL CACHORRO CONDENADO A MUERTE...
	-- Crónica TV
Sep 27 2009
prev sibling next sibling parent reply Vincenzo Ampolo <vincenzo.ampolo gmail.com> writes:
Leandro Lucarella wrote:


 http://www.dsource.org/projects/dmd/timeline


Thanks Walter.

;)

Now, thanks to the public svn we can track changes easily. This will help 
development of gdc too!

Btw today Michael merged dmd 1.035 and i'm close to finish dmd 2.015

See you.
Sep 28 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Vincenzo Ampolo wrote:

 Now, thanks to the public svn we can track changes easily. This will help 
 development of gdc too!


I'm glad you guys have picked up gdc.

There are some tricky bits to doing contract inheritance, I hope gdc and 
ldc don't have trouble with it.
Sep 28 2009
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
<snip>

 There are some tricky bits to doing contract inheritance, I hope gdc and 
 ldc don't have trouble with it.


What tricky bits are those?

Stewart.
Oct 01 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Stewart Gordon wrote:

 Walter Bright wrote:
 <snip>

 There are some tricky bits to doing contract inheritance, I hope gdc 
 and ldc don't have trouble with it.


 
 What tricky bits are those?


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.
Oct 01 2009
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 Stewart Gordon wrote:

 Walter Bright wrote:
 <snip>

 There are some tricky bits to doing contract inheritance, I hope gdc 
 and ldc don't have trouble with it.


 What tricky bits are those?


 
 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.


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.  But in any 
case, thank you for finally getting round to it!

Stewart.
Oct 01 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.)
Oct 01 2009
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Oct 02 2009
prev sibling parent Kagamin <spam here.lot> writes:
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.
Oct 05 2009
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
You guys are doing awesome job with GDC, thank you _VERY MUCH_!

GDC is the only D2 compiler for 64bit architecture...
Sep 30 2009
parent reply Robert Clipsham <robert octarineparrot.com> writes:
Dejan Lekic wrote:

 You guys are doing awesome job with GDC, thank you _VERY MUCH_!
 
 GDC is the only D2 compiler for 64bit architecture...


Actually, there are no D2 compilers for 64 bit. GDC's support for D2 is 
very minimal, I don't know how it compares to LDC's, but I'd guess they 
were about the same (GDC might be slightly further ahead actually, I've 
never tried it). Either way, DMD is pretty much the only choice for a D2 
compiler currently.
Sep 30 2009
parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
LDC2 does not work at all on my 64bit GNU/Linux box, while GDC works  
without any problems (v2.014). Also D2 applications I wrote work well too.  
Sure, old version of D2 is supported so many cool features are missing,  
that is why I hoped some more up-to-date version of GDC will soon be  
released.

D is loosing in popularity these days. Personally, i think one of the  
major reasons is the stale development of GDC. (Yes I am aware of the LDC  
project, but it is quite new one, and lacks working D2 support).
Oct 23 2009
prev sibling next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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.
Oct 05 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 05 2009
parent reply BCS <none anon.com> writes:
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.
Oct 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 06 2009
parent reply Robert Clipsham <robert octarineparrot.com> writes:
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?
Oct 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Clipsham wrote:

 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?


I suggest setting it up to email the maintainers of the packages being 
compiled any problems with compiling them.
Oct 06 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  6 de octubre a las 12:07 me escribiste:

 Robert Clipsham wrote:

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?


 
 I suggest setting it up to email the maintainers of the packages
 being compiled any problems with compiling them.


I think it would be best to have a newsgroup/mailing list/RSS for this.
At least being able to see the result in a website.

I'm very curious, I'd love to be able to see the results of this automated
tests =)

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
HACIA NEUQUEN: EL JUEVES SALDRA CARAVANA CON PERROS
DESDE CAPITAL EN APOYO AL CACHORRO CONDENADO A MUERTE
	-- Crónica TV
Oct 06 2009
parent Moritz Warning <moritzwarning web.de> writes:
On Tue, 06 Oct 2009 21:28:58 -0300, Leandro Lucarella wrote:


 Walter Bright, el  6 de octubre a las 12:07 me escribiste:

 Robert Clipsham wrote:

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?


 
 I suggest setting it up to email the maintainers of the packages being
 compiled any problems with compiling them.


 
 I think it would be best to have a newsgroup/mailing list/RSS for this.
 At least being able to see the result in a website.
 
 I'm very curious, I'd love to be able to see the results of this
 automated tests =)


A website would be my personal favorite.
It's open to everyone and don't spam the mail folder
in times of broken code.
Oct 13 2009
prev sibling parent reply Don <nospam nospam.com> writes:
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.
Oct 06 2009
parent reply Robert Clipsham <robert octarineparrot.com> writes:
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.
Oct 06 2009
parent Christian Kamm <kamm-incasoftware removethis.de> writes:
Robert Clipsham wrote:

 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.


That's true. I've updated the front page with my email address and the 
request for help.
Oct 06 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:


 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.


With small commits to dmd, it should be trivial to know what small change in
dmd caused a user observable change in behavior. If things look good on the dmd
side, I'd really hope the code authors would help with debugging their code.

Knowing of a failure within an hour is way better than finding out a month
later.

BTW, such regression tests work much better when all failing tests can be
identified. It can help with figuring out patterns. Stopping on the first
failure can be somewhat limiting, especially if the failure will stick around
for a week.
Oct 05 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Walter Bright Wrote:
 

 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.


 
 With small commits to dmd, it should be trivial to know what small
 change in dmd caused a user observable change in behavior. If things
 look good on the dmd side, I'd really hope the code authors would
 help with debugging their code.
 
 Knowing of a failure within an hour is way better than finding out a
 month later.
 
 BTW, such regression tests work much better when all failing tests
 can be identified. It can help with figuring out patterns. Stopping
 on the first failure can be somewhat limiting, especially if the
 failure will stick around for a week.


We clearly can't define the language around a best-effort kind of flow 
analysis. I consider Walter's extra checks during optimization a nice 
perk, but definitely not something we can consider a part of the 
language. The language definition must work without those.

Andrei
Oct 05 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  5 de octubre a las 19:17 me escribiste:

 Jason House wrote:

Walter Bright Wrote:


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.


With small commits to dmd, it should be trivial to know what small
change in dmd caused a user observable change in behavior. If things
look good on the dmd side, I'd really hope the code authors would
help with debugging their code.

Knowing of a failure within an hour is way better than finding out a
month later.

BTW, such regression tests work much better when all failing tests
can be identified. It can help with figuring out patterns. Stopping
on the first failure can be somewhat limiting, especially if the
failure will stick around for a week.


 
 We clearly can't define the language around a best-effort kind of
 flow analysis. I consider Walter's extra checks during optimization
 a nice perk, but definitely not something we can consider a part of
 the language. The language definition must work without those.


I guess you answered to the wrong mail, Jason is talking about Robert's
offering to set up a build/test bot for DMD, to build and test each
commit, using dstress and maybe other popular libraries/programs.

-- 
Leandro Lucarella (AKA luca)                      http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
When I was a child I had a fever
My hands felt just like two balloons.
Now I've got that feeling once again
I can't explain you would not understand
This is not how I am.
I have become comfortably numb.
Oct 05 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:

 With small commits to dmd, it should be trivial to know what small
 change in dmd caused a user observable change in behavior.


The problem is, one doesn't know if it is a problem with the change or 
if it is a problem with the user code. To determine that requires 
working with and understanding the user code. It's just impractical for 
me to do that with a large base of code like that.


 If things
 look good on the dmd side, I'd really hope the code authors would
 help with debugging their code.
 
 Knowing of a failure within an hour is way better than finding out a
 month later.
 
 BTW, such regression tests work much better when all failing tests
 can be identified. It can help with figuring out patterns. Stopping
 on the first failure can be somewhat limiting, especially if the
 failure will stick around for a week.
Oct 05 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:


 Jason House wrote:

 With small commits to dmd, it should be trivial to know what small
 change in dmd caused a user observable change in behavior.


 
 The problem is, one doesn't know if it is a problem with the change or
 if it is a problem with the user code. To determine that requires
 working with and understanding the user code. It's just impractical for
 me to do that with a large base of code like that.


But you don't have to take the stance that no regressions may occur (for 
this very reason). 

I think automated builds + tests can be useful in different ways:
- the authors of the code can be notified and look at the problem. Some will 
care and help you spot bugs earlier or may fix their own code earlier. This 
is at no cost to you. Eventually, this task can perhaps be delegated 
completely?
- when a lot of stuff breaks, it is an indicator at least.
- while you may need a lot of investment to determine all problems, at least 
some category of problems you may recognize quickly.
Oct 06 2009