View mode: basic / threaded / horizontal-split · Log in · Help
March 26, 2009
Re: State of Play
On Thu, Mar 26, 2009 at 6:07 PM, Walter Bright
<newshound1@digitalmars.com> wrote:
>
> But that's why the download page divides the downloads into "latest" and
> "stable." If you want "stable", why download "latest"?

Stable doesn't just mean "not changing."  It also means "providing a
strong foundation upon which something can be built."  The older
compilers are usually anything but that, as the newer ones usually fix
more things than what they break.  The library developers are forced
to use newer compilers because there are showstopping bugs in the
older ones, and the library users are then forced to use newer
compilers as a result.  At least, that's what I've experienced.

> Furthermore, before release, it is made available to the DWT and Tango teams
> to see if it breaks them. If I made it generally available, how is that
> different from the "latest" on the download page? There's even a "bundle"
> version that comes with various libraries tested and verified with it.

Well usually problems only arise when things change - directory
structure, new features, language spec changes (.init).  Bugfixes
rarely create problems.  For example I'd welcome fixes to things like
bugs 313 and 314 (which are ancient, by the way) even if it means I
have to change my code, because I know that my code is more correct as
a result.  I feel like the idea behind the nightly releases is so that
when _changes_ occur, or when regressions are introduced, they can be
stamped out before a major release.  DWT and Tango are major projects
but are by no means an exhaustive testbed.

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.
March 26, 2009
Re: State of Play
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.
March 26, 2009
Re: State of Play
Walter Bright schrieb:
> As for the does one develop stable code targeting D1 and D2, I would 
> suggest targeting D1 but be careful to use the string alias for all the 
> char[]'s, and treat strings as if they were immutable. This will cover 
> 90% of any source code changes between D1 and D2, perhaps even more than 
> 90%. It's also very possible to write D1 code using the immutability 
> style, in fact, I advocated it long before D2 (see all the old threads 
> discussing Copy On Write).

Well, using the string alias leads to problems, esp. when used as a 
function parameter:
int func(string str)

This makes it impossible to pass a mutable string to the function in D2.

I personally use an  alias const(char)[] cstring;  for most of my 
parameters and  alias invariant(char)[] istring;  for normal immutable 
strings.
March 26, 2009
Re: State of Play
On Thu, Mar 26, 2009 at 7:01 PM, 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.

It's not the bugs that you know about that cause problems for other people!
March 26, 2009
Re: State of Play
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.
March 27, 2009
Re: D1.x series proposal [was: State of Play]
Sean Kelly, el 26 de marzo a las 22:08 me escribiste:
> == Quote from Leandro Lucarella (llucax@gmail.com)'s article
> >
> > D situation is a little different because D2 is already here, and it's too
> > much ahead of D1. So a plan to backport features from D2 to D1
> > progressively should be done.
> 
> Who is going to do these backports?

That's a fair question without an answer =)
(I wish I had the time to do it. If I had the time I probably first do it
and then propose it)

> Personally, I'd rather think about moving my code to D2 in one jump than
> in a bunch of incremental steps, each requiring a custom compiler.

Are you? If not, why? I think D2 being a moving target make people don't
want to port code because it would be too hard to maintain. They idea
behind 1.x series is that each minor version is *stable*. Code you port
to, let's say, 1.1.000, will work with 1.1.100. No new predefined
versions, no new nothing. You get a really stable language and one that
evolves fast. You just have to do some minor porting about once a year,
when a new minor version is release, and that porting should be trivial.
Porting code to D2 now is a complicated excercise, at least to do it right
(using constness features).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Algún día los libros desterrarán a la radio y el hombre descubrirá el
oculto poder del Amargo Serrano.
	-- Ricardo Vaporeso. El Bolsón, 1909.
March 27, 2009
Re: State of Play
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.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
ease, eating well (no more microwave dinners and saturated fats),
a patient better driver, a safer car (baby smiling in back seat),
sleeping well (no bad dreams), no paranoia,
March 27, 2009
Re: State of Play
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).
March 27, 2009
Re: State of Play
On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax@gmail.com> 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.


I think part of the problem with the current approach is that the
"stable" D releases seem to have no connection with reality.  It's
always been way older than it should be every time I've looked.  I
wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037
should be the most recent "stable" version at the moment.   It seems
there isn't a good process in place for figuring out what's stable and
what's not.

It seems to me the only people who would know which compilers deserve
the "stable" label are the folks using dmd on a daily basis to build
their software.  Yet I've never seen the question come up here or
anywhere else of what version of D the users find to be the most
stable.   My impression is frankly that Walter just arbitrarily slaps
the label on a rev that's about 10 steps back from current.  Probably
there's more to it than that, but that's what it seems like.

--bb
March 27, 2009
Re: State of Play
Bill Baxter wrote:
> On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax@gmail.com> 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.
> 
> 
> I think part of the problem with the current approach is that the
> "stable" D releases seem to have no connection with reality.  It's
> always been way older than it should be every time I've looked.  I
> wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037
> should be the most recent "stable" version at the moment.   It seems
> there isn't a good process in place for figuring out what's stable and
> what's not.
> 
> It seems to me the only people who would know which compilers deserve
> the "stable" label are the folks using dmd on a daily basis to build
> their software.  Yet I've never seen the question come up here or
> anywhere else of what version of D the users find to be the most
> stable.   My impression is frankly that Walter just arbitrarily slaps
> the label on a rev that's about 10 steps back from current.  Probably
> there's more to it than that, but that's what it seems like.
> 
> --bb

Actually it's more like he moves it forward when conversations like this
come up and point out how far behind it is.  I'm not sure I've seen it
ever pro-actively moved forward, only re-actively. :)

Later,
Brad
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home