July 03, 2007
Christian Kamm wrote:
>> Just bug fixes common to both.
> 
> Great news! And special thanks for fixing bug 540...
> 
> Unfortunately, this code (which appears in derelict) broke
> 
> -
> version(Windows)
>   extern(Windows):
> else
>   extern(C):
> 
> Declaration expected, not 'else'
> -
> 
> Looking around in the spec, I can not find where the StorageClass: syntax is
> defined, so maybe it is supposed to be illegal?
> 
> Cheers,
> Christian

The problem extends just beyond compiler errors, unfortunately: http://dblog.aldacron.net/2007/07/03/derelict-problems-with-dmd-1018/
July 03, 2007
Luís Marques wrote:
> Walter: have you considered keeping a large code base of D projects which you would try to compile and run its unit tests before each release? It would be a akin to dstress, with the added benefit that it would check that major projects are OK with new versions.

I don't do that for several reasons:

1) Running the test suite is already an all night affair. Making it a week long affair makes it fairly unusable.

2) Trying to figure out why some large code base of code I am unfamiliar with fails is a major effort. It's not practical.

3) I find that people tend to program in "islands" of a particular language, no matter how large that program becomes, it only tests a particular "island" of features. So 99.9% of the large program becomes redundant as a test suite.

4) Nearly all bugs can be boiled down to 10 or less lines of code (even ones their submitter swears can't be reduced! <g>). Putting these into the test suite is highly effective. It gives me a very fast check, and since it is very small, when it fails it is a *lot* less work to figure out why.

5) The test suite is a gradual accretion of all those 10 liners. Over time, it gets extremely thorough. The one I have for C/C++ is a distillation of 25 years of bug reports, and the result is it is very rare for any regressions.

To sum up, I find it more useful to target with a rifle rather than carpet bombing!
July 03, 2007
Reply to Walter,

> Luís Marques wrote:
> 
>> Walter: have you considered keeping a large code base of D projects
>> which you would try to compile and run its unit tests before each
>> release? It would be a akin to dstress, with the added benefit that
>> it would check that major projects are OK with new versions.
>> 
> I don't do that for several reasons:
> 
> 1) Running the test suite is already an all night affair. Making it a
> week long affair makes it fairly unusable.
> 

Does anyone else have the time (CPU and brain time) and interest to do this? A script that would check out all the SVN stuff from dsource and run the unittest would get a quite large return for the effort (that assumes stuff has good unittests, a worth goal in and of it's self).


July 03, 2007
BCS wrote:
> Reply to Walter,
> 
>> Luís Marques wrote:
>>
>>> Walter: have you considered keeping a large code base of D projects which you would try to compile and run its unit tests before each release? It would be a akin to dstress, with the added benefit that it would check that major projects are OK with new versions.
>>>
>> I don't do that for several reasons:
>>
>> 1) Running the test suite is already an all night affair. Making it a week long affair makes it fairly unusable.
>>
> 
> Does anyone else have the time (CPU and brain time) and interest to do this? A script that would check out all the SVN stuff from dsource and run the unittest would get a quite large return for the effort (that assumes stuff has good unittests, a worth goal in and of it's self).

I wonder if Gregor could recommend us up some tool to accomplish this?

BA
July 03, 2007
Walter Bright wrote:
> I don't do that for several reasons:
> 
> 1) Running the test suite is already an all night affair. Making it a week long affair makes it fairly unusable.
> 
> 2) Trying to figure out why some large code base of code I am unfamiliar with fails is a major effort. It's not practical.
> 
> 3) I find that people tend to program in "islands" of a particular language, no matter how large that program becomes, it only tests a particular "island" of features. So 99.9% of the large program becomes redundant as a test suite.
> 
> 4) Nearly all bugs can be boiled down to 10 or less lines of code (even ones their submitter swears can't be reduced! <g>). Putting these into the test suite is highly effective. It gives me a very fast check, and since it is very small, when it fails it is a *lot* less work to figure out why.
> 
> 5) The test suite is a gradual accretion of all those 10 liners. Over time, it gets extremely thorough. The one I have for C/C++ is a distillation of 25 years of bug reports, and the result is it is very rare for any regressions.
> 
> To sum up, I find it more useful to target with a rifle rather than carpet bombing!

I have to agree with all points. Thats right, projects owners could do it much more efficiently. And they actually do...

http://dblog.aldacron.net/2007/07/03/derelict-problems-with-dmd-1018/


-- serg.
July 04, 2007
Walter Bright wrote:
> http://www.digitalmars.com/d/changelog.html
> http://ftp.digitalmars.com/dmd.2.002.zip

That first page still links to dmd.2.001.zip as the "latest D 2.0 alpha D compiler" (at the top)
July 04, 2007
Frits van Bommel wrote:
> Walter Bright wrote:
>> http://www.digitalmars.com/d/changelog.html
>> http://ftp.digitalmars.com/dmd.2.002.zip
> 
> That first page still links to dmd.2.001.zip as the "latest D 2.0 alpha D compiler" (at the top)

Not no more!
July 05, 2007
Walter Bright wrote:
> To sum up, I find it more useful to target with a rifle rather than carpet bombing!

Right, right, and treple right! Go on, you... :)

July 08, 2007
Pragma wrote:
> I don't say it enough: Thanks for D and all the effort, Walter.

Thank you. The enthusiasm and support from all you guys is what keeps me going.
1 2 3
Next ›   Last »