Re: DMD svn and contract inheritance
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).
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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?
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.)
Re: DMD svn and contract inheritance
Walter Bright wrote: Stewart Gordon wrote: Walter Bright wrote: 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.
Re: DMD svn and contract inheritance
Stewart Gordon wrote: Walter Bright wrote: 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.
Re: DMD svn and contract inheritance
Walter Bright wrote: 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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
You guys are doing awesome job with GDC, thank you _VERY MUCH_! GDC is the only D2 compiler for 64bit architecture...
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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.
Re: DMD svn and contract inheritance
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
Re: DMD svn and contract inheritance
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.
