On Fri, 27 Mar 2009 23:33:43 +0300, Tomas Lindquist Olsen <tomas.l.olsen@gmail.com> wrote:
> On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Jarrett Billingsley wrote:
>>>
>>> So what about the following counterargument: "even if nightly builds
>>> were made available, how can we be sure that enough people are using
>>> them to sufficiently test them?" OK, sure, if not many people are
>>> using the nightly builds, then there wouldn't be much benefit. But it
>>> does seem to work out fine for a lot of projects. And with a proper
>>> SCM set up which you commit to daily, there's virtually no work on
>>> your part. You just commit, and everyone else can download and
>>> compile.
>>
>> I believe that people downloading half-baked works in progress and then
>> finding problems I already know about and am fixing is probably not more
>> productive.
>>
>
> Some of us might actually look at your changes.
>
> 1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.
>
> 2) We can comment on changes. Ideally there would be a mailing list
> with each commit. This makes discussion of specific changes much
> easier.
>
> 3) You get feedback on the code.
>
> I'm not sure how many people have access to your code, or if you even
> use a SCM repository locally.
>
> As an extra bonus you could release your internal test suite as well.
> This would be useful for projects like LDC, as a compliment to
> DStress. Do you use Dstress?
>
> The testing process of DMD could be much less opaque in general.
>
> -Tomas
>
*Highly* agree!

On Fri, Mar 27, 2009 at 9:33 PM, Tomas Lindquist Olsen
<tomas.l.olsen@gmail.com> wrote:
> On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Jarrett Billingsley wrote:
>>>
>>> So what about the following counterargument: "even if nightly builds
>>> were made available, how can we be sure that enough people are using
>>> them to sufficiently test them?" OK, sure, if not many people are
>>> using the nightly builds, then there wouldn't be much benefit. But it
>>> does seem to work out fine for a lot of projects. And with a proper
>>> SCM set up which you commit to daily, there's virtually no work on
>>> your part. You just commit, and everyone else can download and
>>> compile.
>>
>> I believe that people downloading half-baked works in progress and then
>> finding problems I already know about and am fixing is probably not more
>> productive.
>>
>
> Some of us might actually look at your changes.
>
> 1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.
>
> 2) We can comment on changes. Ideally there would be a mailing list
> with each commit. This makes discussion of specific changes much
> easier.
>
> 3) You get feedback on the code.
>
> I'm not sure how many people have access to your code, or if you even
> use a SCM repository locally.
>
> As an extra bonus you could release your internal test suite as well.
> This would be useful for projects like LDC, as a compliment to
> DStress. Do you use Dstress?
>
> The testing process of DMD could be much less opaque in general.
>
> -Tomas
>
I should have picked another thread to reply to. I have no interest of
nightly builds of DMD.

Denis Koroskin wrote:
> On Fri, 27 Mar 2009 23:33:43 +0300, Tomas Lindquist Olsen <tomas.l.olsen@gmail.com> wrote:
>
>> On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> Jarrett Billingsley wrote:
>>>> So what about the following counterargument: "even if nightly builds
>>>> were made available, how can we be sure that enough people are using
>>>> them to sufficiently test them?" OK, sure, if not many people are
>>>> using the nightly builds, then there wouldn't be much benefit. But it
>>>> does seem to work out fine for a lot of projects. And with a proper
>>>> SCM set up which you commit to daily, there's virtually no work on
>>>> your part. You just commit, and everyone else can download and
>>>> compile.
>>> I believe that people downloading half-baked works in progress and then
>>> finding problems I already know about and am fixing is probably not more
>>> productive.
>>>
>> Some of us might actually look at your changes.
>>
>> 1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.
>>
>> 2) We can comment on changes. Ideally there would be a mailing list
>> with each commit. This makes discussion of specific changes much
>> easier.
>>
>> 3) You get feedback on the code.
>>
>> I'm not sure how many people have access to your code, or if you even
>> use a SCM repository locally.
>>
>> As an extra bonus you could release your internal test suite as well.
>> This would be useful for projects like LDC, as a compliment to
>> DStress. Do you use Dstress?
>>
>> The testing process of DMD could be much less opaque in general.
>>
>> -Tomas
>>
>
> *Highly* agree!
>
2nded

Jason House wrote:
> I think many people avoid D2 because it has const and that const is too much work for too little gain. Many seem to want all features of D2 without the const. I don't really get any of the anti D2 arguments except that D2 lacks Tango. I pushed hard trying to see something official in that area, including offering my time totest/fix Tango after breaking D2 changes. I've given up on the whole mess.
I *want* to use const. But it's too much work. I want const by default,
since that would let me be lazy and let the compiler tell me where
things can't be const.

Walter Bright wrote:
> Leandro Lucarella wrote:
>> Walter Bright, el 26 de marzo a las 16:58 me escribiste:
>>> Jarrett Billingsley wrote:
>>>> It's not the bugs that you know about that cause problems for other
>>>> people!
>>> Half-baked implementations won't help them, either. I just don't think
>>> the answer is, what is in essence, a lot more releases.
>>
>> Millions of open source projects that work that way can prove you wrong.
>
> Phobos works that way, and intermediate "releases" are pretty much
> ignored (as I think they should be).
I ignore them because:
1. I don't use phobos
2. They sometimes rely on compiler features that won't be available for
another few weeks
On the other hand, I get tango from svn rather than the last release as
a matter of course. And when using LDC, I update roughly once a week --
more often if I experience bugs.

Christopher Wright Wrote:
> I *want* to use const. But it's too much work. I want const by default,
> since that would let me be lazy and let the compiler tell me where
> things can't be const.
I wish for the same thing. "in" parameters by default would be great. One of these days, I'll add const-awareness to my D2 code...

Tomas Lindquist Olsen wrote:
> As an extra bonus you could release your internal test suite as well.
> This would be useful for projects like LDC, as a compliment to
> DStress. Do you use Dstress?
The problem with releasing the test suite I use is that its heritage is
not very clear. It's quite a grab-bag collection of everything that went
wrong in the past. Parts of it come from Dstress, too.
> The testing process of DMD could be much less opaque in general.
>
> -Tomas

Tomas Lindquist Olsen, el 27 de marzo a las 21:35 me escribiste:
> >>> So what about the following counterargument: "even if nightly builds
> >>> were made available, how can we be sure that enough people are using
> >>> them to sufficiently test them?" OK, sure, if not many people are
> >>> using the nightly builds, then there wouldn't be much benefit. But it
> >>> does seem to work out fine for a lot of projects. And with a proper
> >>> SCM set up which you commit to daily, there's virtually no work on
> >>> your part. You just commit, and everyone else can download and
> >>> compile.
[snip]
> I should have picked another thread to reply to. I have no interest of
> nightly builds of DMD.
BTW, when I originally said "nightly builds" I ment "nightly snapshots",
which is a poor man aproximation to an SCM. An SCM would be ideal, of
course.
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
RENUNCIO PARA IR A REZARLE A SAN CAYETANO
-- Crónica TV