www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD needs branches

reply "Chris Miller" <chris dprogramming.com> writes:
I'm sure this was brought up in the past, but DMD definitely needs stable  
and unstable branches.

-v1 doesn't cut it. My code is compiled with -v1 and still breaks with new  
DMD versions.

Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!

How am I supposed to let others use my code when there's no stability in  
the compiler? They update their compiler and report to me "your code is  
broken"; well, no, DMD is broken.

I have a ton of code that doesn't work on any of the new DMD compilers; I  
have to use an old pre-1.0 compiler, because the recent compilers are  
bug-ridden. Some bugs get fixed, but even more get added.

I'm sure a lot of you out there have similar experiences. Speak up now,  
please!

With each new release I get more and more frustrated with D. There's no  
stability! I know you want more and more features, but how can I keep  
using a language like this?

-

I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard  
as hell and time consuming. I need time to report bugs. Now I have to  
either restrict use to specific compiler versions, which people don't  
always know about and report their issues back to me, until I remind them  
they need to downgrade their compiler (which isn't always an option if  
they need bug fixes), or I have to rush to fix my code to workaround such  
issues and report bugs. If there was a stable branch, I could get the code  
working with the unstable branch at a reasonable pace.

-

D 1.0 means nothing. The 1.0 release was a huge flop. I think it could  
have done so much better and retained more users. We need some stability  
and to try the big release one more time. "D 1.1 release 'whoops, got it  
right this time'" (hopefully).

Also, the documentation should probably clearly state differences between  
versions, perhaps even with the words "unstable" near the things not in  
the stable branch. (Safe to ignore 1.0 since it's pointless.)

-

I've had all this in the back of my mind for quite some time and I've  
tried to be patient about it. I'm not trying threaten anyone, but I don't  
know how much longer I'm going to put up with D with its current methods.  
Note that I am probably one of the oldest D users still using it.

-

Thanks for your time.

- Christopher E. Miller
www.dprogramming.com
miller[] on #D freenode.
Apr 11 2007
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Yes, thats what i also thought.
Please do this little extra work,
it would be a really big quality enhancement.
Apr 11 2007
prev sibling next sibling parent Frederico Wagner <lectus lectus.com> writes:
I agree.
D really needs 2 branches:
* 1.x would be a bug fixes only version. (stable)
* 2.0 would be a new features and bug fixes version. (unstable, language
expansion version)

After some time, for example, 1 year, it would merge the 2.0 branch into the
stable branch and do it again. (2.x and 3.0 branches).
So users could keep using DMD until there's a new stable version, and they
could port / fix the code to be compatible with the new stable release.

If DMD stays very unstable as it is it will be forever having broken libraries,
which will slow down the development of possible frameworks and tools. Because
of this one-version-only compatibility.
And this is a bad thing for the growing of the language and the community
itself.

It's very sad to have a hard work with some project and then you find out that
it doesn't work with the new compiler version, and you have to fix this very
quickly because users want updated compilers to use with your library. With the
stable branch we would keep using it and every library would work OK.
If someone decides to use the unstable DMD version this person would do it
knowing that it may not be compatible with current libraries and source codes.

I hope the developers of D do something about this.
miller[] is really a very active user of D and is doing great work coding
libraries.
If the current problem is making he write this, I think this is a serious
problem that might be affecting other users as well.
Sorry, for my bad english. And I hope you understand what I'm saying.

Thanks.

Frederico Wagner
Lectus on #D freenode.
Apr 11 2007
prev sibling next sibling parent Marcin Kuszczak <aarti interia.pl> writes:
Chris Miller wrote:

 
 I've had all this in the back of my mind for quite some time and I've
 tried to be patient about it. I'm not trying threaten anyone, but I don't
 know how much longer I'm going to put up with D with its current methods.
 Note that I am probably one of the oldest D users still using it.
 
I agree with you. Additionally I think there are some really good Open Source ways of working which are much more productive than current way of developing D. I mean e.g. SVN repository (encourages to prepare patches), some kind of tracking of enhancement requests (better than bugzilla), better way of packaging compiler with standard library (I really can not get clue why linux and windows versions of dmd are mixed in one packages; additionally breaking packages into DMD/DMC while have same merits is not very user friendly), more people with "write rights" for DMD/Phobos, eventually even help for Tango people (e.g. bundling it with DMD or support in DMD for other standard libraries not just Phobos). I can live with current state, but I am sure that definitely using good standards from other successfull projects would help D much more than super hyper new features. (I am not against constness, as it look as very important feature, but macros... well...). There are also some rough edges in D which should be polished probably with higher priority than adding new features... Just a few additional thoughts... -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Apr 11 2007
prev sibling next sibling parent BCS <BCS pathlink.com> writes:
I second the notion, big time.
Apr 11 2007
prev sibling next sibling parent reply Tyler Knott <tywebmail mailcity.com> writes:
I'm seconding this; branches would be much appreciated for all the reasons
other 
have posted.
Apr 11 2007
parent Dan <murpsoft hotmail.com> writes:
I second branching if -v1 doesn't perfectly imitate the state of the 1.0
compiler.

I also second the motion for putting D development and sources on SVN - in
spite of my feelings for SVN nomenclature.

If the powers-that-be agree, then I would suggest moving it to SVN, taking the
1.0 release as-is, and then carefully merge-diff'ing it up to current for bug
fixes.
Apr 11 2007
prev sibling next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.tqmzf7bzpo9bzi tanu2003.tanu2003net.local...
 I'm sure this was brought up in the past, but DMD definitely needs stable 
 and unstable branches.

 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with new 
 DMD versions.

 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!

 How am I supposed to let others use my code when there's no stability in 
 the compiler? They update their compiler and report to me "your code is 
 broken"; well, no, DMD is broken.

 I have a ton of code that doesn't work on any of the new DMD compilers; I 
 have to use an old pre-1.0 compiler, because the recent compilers are 
 bug-ridden. Some bugs get fixed, but even more get added.

 I'm sure a lot of you out there have similar experiences. Speak up now, 
 please!

 With each new release I get more and more frustrated with D. There's no 
 stability! I know you want more and more features, but how can I keep 
 using a language like this?

 -

 I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard 
 as hell and time consuming. I need time to report bugs. Now I have to 
 either restrict use to specific compiler versions, which people don't 
 always know about and report their issues back to me, until I remind them 
 they need to downgrade their compiler (which isn't always an option if 
 they need bug fixes), or I have to rush to fix my code to workaround such 
 issues and report bugs. If there was a stable branch, I could get the code 
 working with the unstable branch at a reasonable pace.

 -

 D 1.0 means nothing. The 1.0 release was a huge flop. I think it could 
 have done so much better and retained more users. We need some stability 
 and to try the big release one more time. "D 1.1 release 'whoops, got it 
 right this time'" (hopefully).

 Also, the documentation should probably clearly state differences between 
 versions, perhaps even with the words "unstable" near the things not in 
 the stable branch. (Safe to ignore 1.0 since it's pointless.)

 -

 I've had all this in the back of my mind for quite some time and I've 
 tried to be patient about it. I'm not trying threaten anyone, but I don't 
 know how much longer I'm going to put up with D with its current methods. 
 Note that I am probably one of the oldest D users still using it.
I agree. If D ever wants to be practically deployable in the real world it has to be stable; coders need to have a relatively consistent compiler and language and say "here, this is d."
 -

 Thanks for your time.

 - Christopher E. Miller
 www.dprogramming.com
 miller[] on #D freenode. 
Apr 11 2007
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs 
 stable and unstable branches.
Agreed.
 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with 
 new DMD versions.
Same here.
 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!
It's even worse than this in my case. With a few friends, I'm doing a project for the Team Programming course at my univ. It's a First Person Shooter, containing more than 55k lines of our own D code plus some 200k of dependencies, such as DDL, Mango, Code Analyzer, Derelict, Enki, MinTL and various bindings. And we're stuck with... DMD 0.175. I've tried every single DMD release which came after 0.175, including 1.010b, and each has its own problems. The old bugs get slowly fixed, but new ones appear at a frightening pace. DMD 1.011 adds some more mixin issues to the pile, and even with -v1, considers 'ref' a keyword. The worst problems with the new DMDs are codegen issues. For instance, http://d.puremagic.com/issues/show_bug.cgi?id=1068 Earlier, 1.007 had a weird NRVO problem. It could return garbage from functions when their calls appeared at the return statement. It seems to be gone, but no one filled a bug report and I'm not sure if it's not just lurking someplace else. My team and me have first got stuck with DMD 0.175 when 0.176 changed the ABI and DDL stopped working for us. But then I updated DDL to the ABI of DMD 1.0. I can't even test it because bugs have appeared over the time. Some made Mango not compile, thus sending DDL to bite the dust as well. The latest and best one is the invalid codegen issue from the link above. I can't even make our game's GUI run because I'm getting random access violations. After updating to DMD 1.011, I had some errors telling me about it not being able to find identifiers that certainly were there. Yet Another Mixin Bug. D really needs to get stable before anything serious can be made in it... Not that I don't like the new features. The CTFE, mixins and smarter IFTI are just great... If only I could use them. Our project contains numerous workarounds for the issues in DMD 0.175 because we can't just report a bug and hope we'll be able to continue with the next DMD release. We're stuck with 0.175 and we've been stuck with it for the last 5 months. I'm a huge fan of D and a long-time user, but I simply don't know what to tell people when they ask why we're using some archaic 0.175 version and not the new one with all the spiffy features. Please, fix D. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Apr 11 2007
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs 
 stable and unstable branches.
 
 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with 
 new DMD versions.
 
 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!
 
What are, say, the three major bugs that are preventing you from compiling code? Don't get me wrong - I can understand your frustration (and thanks for DFL, Entice, et al), and I'm not discounting your problems, but I guess I haven't seen or heard that the newer compilers were more 'buggy' than the old. I thought quite a few things had actually improved since the pre-1.0 days. DStress (http://dstress.kuehne.cn/www/dstress.html) seems to show steady improvement anyhow. IMHO, since Walter is only one person, what you're asking for (branches) may actually have the unintended consequence of slowing down the fixes. For many of the bugs, it would probably require making mods. to two diverging code bases. Thanks, - Dave
Apr 11 2007
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 11 Apr 2007 16:34:45 -0400, Chris Miller wrote:

 I'm sure this was brought up in the past, but DMD definitely needs stable  
 and unstable branches.
YES YES YES! -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Apr 11 2007
prev sibling next sibling parent =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs
 stable and unstable branches.
About the biggest problems.. I find it difficult to keep track of the changes. The docs are now much better than what they were in 2003 when I started using D, but they could be so much more. There are some real problems in the current development model. First, the DMD frontend is used by many entities (Mr. Bright, Mr. Friedman, Mr. Richards and several others). Of course there are several pairs of eyes also constantly hunting bugs from it. Many have created their own installation scripts to update to a new release. Now, wouldn't it be much easier to have a central repository for anyone to access? I mean, although DMD 1.x is now out, it isn't so much more stable than the 0.1xx beta releases. Maybe even create experimental branches so the community could test patches with GDC before applying them to official DMD. Another thing is documentation. DDOC generates nicely formatted pages without much trouble. It should be possible to test embedded example code by just compiling them. IIRC there have been bug reports about examples that are not even syntactically correct. Another thing is the pages don't currently contain metadata, e.g. version tags. This would probably require some sort of server side wiki software. The Trac project (although not best for pure documentation) is a good example of this. It allows one to create reports about fixed bugs and then cut'n'paste those to release announcements (possibly even automatically). How could community help more? When I find a bug in the documentation I'm not sure should I even report it. I mean, e.g. fixing a single missing 'n' requires a lot of bureaucracy. First logging to bugzilla, searching for previous reports, writing the report, someone reading it, actually fixing it, and marking as fixed. It could all be done by a (even novice) community member. Maybe sharing the user identification info with dsource could help, allowing rw access to trusted members. I want to thank Walter for creating D and the community for helping me throughout the years. D is a wonderful language, but those bugs are hurting big projects like Deadlock a lot. It's great to see high level proof-of-concept stuff like BLADE gets attention. After all, that brings the publicity. But please don't forget the real users with real world projects.
Apr 11 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard 
 as hell and time consuming. I need time to report bugs. Now I have to 
 either restrict use to specific compiler versions, which people don't 
 always know about and report their issues back to me, until I remind 
 them they need to downgrade their compiler (which isn't always an option 
 if they need bug fixes), or I have to rush to fix my code to workaround 
 such issues and report bugs. If there was a stable branch, I could get 
 the code working with the unstable branch at a reasonable pace.
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
Apr 11 2007
next sibling parent Roberto Mariottini <rmariottini mail.com> writes:
Walter Bright wrote:
 Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is 
 hard as hell and time consuming. I need time to report bugs. Now I 
 have to either restrict use to specific compiler versions, which 
 people don't always know about and report their issues back to me, 
 until I remind them they need to downgrade their compiler (which isn't 
 always an option if they need bug fixes), or I have to rush to fix my 
 code to workaround such issues and report bugs. If there was a stable 
 branch, I could get the code working with the unstable branch at a 
 reasonable pace.
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
I think it's not a matter of a few issues. I think the problem is in the _language_ changes. Branching is something that works very well in many projects (the Linux kernel is one notable example) but also all of my projects are version-based, with one branch per version. Using CVS or Subversion makes this very easy: you make the modification on the main trunk, then selectively apply them to the desired branches. This worked flawlessly for me, saving me a lot of problems and headaches. The STABLE branch is something old and working, without all the new whistles and bells, but that can compile legacy code(1). The main trunk, aka the UNSTABLE branch, is something new, with all the new features available, but possibly breaks old code. I know that maintaining the current compiler is already a demanding task, but maintaining only one stable version is not that difficult. Simply branch the code at a particular version and keep working on the new code. If you find that a bug fix can also be applied to the old code then apply it. If fixing the bug in the old code is too much work and/or the bug is not applicable to the new code, then document it and say simply: "this is a known bug and will be fixed in the next major release". The change of major version can be done once a year: the STABLE compiler is considered OLD and no more updated, the UNSTABLE compiler branches becoming both the STABLE branch and the UNSTABLE main trunk. This always worked for me. Ciao (1) What is "legacy code"? "Legacy code" is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer consider outdated and/or (2) is competing with something sold/promoted by the speaker/writer. "Legacy code" often differs from its suggested alternative by actually working and scaling. (from the Stroustrup FAQ: http://www.research.att.com/~bs/bs_faq.html#legacy)
Apr 12 2007
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard
 as hell and time consuming. I need time to report bugs. Now I have to
 either restrict use to specific compiler versions, which people don't
 always know about and report their issues back to me, until I remind
 them they need to downgrade their compiler (which isn't always an option
 if they need bug fixes), or I have to rush to fix my code to workaround
 such issues and report bugs. If there was a stable branch, I could get
 the code working with the unstable branch at a reasonable pace.
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
This was said (many times!) back when the date for 1.0 was decided upon - there is no single point in making such a milestone, if there is no actual way for the user to have it enforced. One could argue that they should stick with DMD 1.000, but it has serious bugs too which has been fixed in later releases, but when these releases create new bugs (even when using the -v1 switch), then you in reality have no stable 1.0 branch. It is useless as it is. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Apr 12 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is hard
 as hell and time consuming. I need time to report bugs. Now I have to
 either restrict use to specific compiler versions, which people don't
 always know about and report their issues back to me, until I remind
 them they need to downgrade their compiler (which isn't always an option
 if they need bug fixes), or I have to rush to fix my code to workaround
 such issues and report bugs. If there was a stable branch, I could get
 the code working with the unstable branch at a reasonable pace.
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
This was said (many times!) back when the date for 1.0 was decided upon - there is no single point in making such a milestone, if there is no actual way for the user to have it enforced. One could argue that they should stick with DMD 1.000, but it has serious bugs too which has been fixed in later releases, but when these releases create new bugs (even when using the -v1 switch), then you in reality have no stable 1.0 branch. It is useless as it is.
The test suite is run before every new release. If things break with a new release, it is because the case isn't reflected in the test suite. Every fixed bug goes in to the test suite. For example, Kris posted two things that broke with the 1.011 update. Both are fixed now, and both are now in the test suite. They'll stay fixed. Over time, the suite has a ratchet effect, with things getting better and better. I've been using that system for decades with the C++ compiler, and it's pretty rare for an update to break anything. But if bugs aren't reported, then they don't get fixed, and the test case never winds up in the test suite. The only way to get a stable system is to report bugs, fix them, and put the cases in the test suite. I tend to put priority on fixing things that break existing code; I know how maddening that can be.
Apr 12 2007
next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
I think, it is not necessary to have long living stable branches.
Only to have the bugs fixed in one version shall be applied also to the
previous version.

Actually it is dmd 1.011
in few week you will release dmd 1.012
why not simple make two releases?
dmd 1.012 only bug fixes
dmd 1.013 bugfixes and enhancements

So there is a better chance, that more ppl can catch up.
Apr 12 2007
parent Carlos Santander <csantander619 gmail.com> writes:
Frank Benoit (keinfarbton) escribió:
 I think, it is not necessary to have long living stable branches.
 Only to have the bugs fixed in one version shall be applied also to the
 previous version.
 
 Actually it is dmd 1.011
 in few week you will release dmd 1.012
 why not simple make two releases?
 dmd 1.012 only bug fixes
 dmd 1.013 bugfixes and enhancements
 
 So there is a better chance, that more ppl can catch up.
This would be a good, simple solution, I think. Maybe not as good as having branches, but it would work. -- Carlos Santander Bernal
Apr 12 2007
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is
 hard as hell and time consuming. I need time to report bugs. Now I have
 to either restrict use to specific compiler versions, which people
 don't always know about and report their issues back to me, until I
 remind them they need to downgrade their compiler (which isn't always
 an option if they need bug fixes), or I have to rush to fix my code to
 workaround such issues and report bugs. If there was a stable branch, I
 could get the code working with the unstable branch at a reasonable
 pace.
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
This was said (many times!) back when the date for 1.0 was decided upon - there is no single point in making such a milestone, if there is no actual way for the user to have it enforced. One could argue that they should stick with DMD 1.000, but it has serious bugs too which has been fixed in later releases, but when these releases create new bugs (even when using the -v1 switch), then you in reality have no stable 1.0 branch. It is useless as it is.
The test suite is run before every new release. If things break with a new release, it is because the case isn't reflected in the test suite. Every fixed bug goes in to the test suite. For example, Kris posted two things that broke with the 1.011 update. Both are fixed now, and both are now in the test suite. They'll stay fixed. Over time, the suite has a ratchet effect, with things getting better and better. I've been using that system for decades with the C++ compiler, and it's pretty rare for an update to break anything. But if bugs aren't reported, then they don't get fixed, and the test case never winds up in the test suite. The only way to get a stable system is to report bugs, fix them, and put the cases in the test suite. I tend to put priority on fixing things that break existing code; I know how maddening that can be.
Point is that every new feature is likely to create new bugs that will make an upgrade difficult. And as long as more new bugs appear than what is closed, your solution will not work. You can't compare with your C++ compiler either, as it is not implementing a specification in constant flux. Using a revision system tend to make it very easy to apply just bugfixes to one branch, and new features _and_ bugfixes to the development branch. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Apr 12 2007
prev sibling parent Mark Wrenn <mark-nospam binarytheory.com> writes:
Hmmm...Wouldn't it be cool if dsource.org ran overnight builds.  This 
would substantially increase the 'test suite'.  Of course you could 
never be sure if a failure was a check-in problem or a compiler problem. 
  But if it succeeded then you'd end up feeling much more confident 
about a new compiler release.

Mark


Walter Bright wrote:
 
 The test suite is run before every new release. If things break with a 
 new release, it is because the case isn't reflected in the test suite. 
 Every fixed bug goes in to the test suite. For example, Kris posted two 
 things that broke with the 1.011 update. Both are fixed now, and both 
 are now in the test suite. They'll stay fixed.
 
 Over time, the suite has a ratchet effect, with things getting better 
 and better. I've been using that system for decades with the C++ 
 compiler, and it's pretty rare for an update to break anything.
 
 But if bugs aren't reported, then they don't get fixed, and the test 
 case never winds up in the test suite.
 
 The only way to get a stable system is to report bugs, fix them, and put 
 the cases in the test suite. I tend to put priority on fixing things 
 that break existing code; I know how maddening that can be.
Apr 12 2007
prev sibling next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
Walter Bright wrote:
 Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is 
 hard as hell and time consuming. I need time to report bugs. Now I 
 have to either restrict use to specific compiler versions, which 
 people don't always know about and report their issues back to me, 
 until I remind them they need to downgrade their compiler (which isn't 
 always an option if they need bug fixes), or I have to rush to fix my 
 code to workaround such issues and report bugs. If there was a stable 
 branch, I could get the code working with the unstable branch at a 
 reasonable pace.
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
What we're trying to say, I think, is that we simply need two compiler branches. D 1.x Compiler + Documentation Branch w/ bug fixes only D 2.x Compiler + Documentation Branch w/ features & bug fix The problem is that folks need a compiler that is consistent and stable, and constantly adding new features to the compiler inherently undermines its stability. We could report bugs, but why report bugs when this fundamental issue can be solved by a simple change of compiler development? Some of us have little time on our hands to develop in D, but when developing, would rather spend our time coding D then going on bug report brigades which are seemingly entirely avoidable. For example: even though DMD v1.0 doesn't use the 'ref' keyword, using the -v1 switch still allows you to use the 'ref' keyword and it works as expected. These types of problems, I imagine, must be more difficult to handle only having one compiler branch. With two compiler branches, these problems will never crop up in the first place. I know two compiler branches might be more difficult to maintain and will probably consume 2x more development time on your part, but I imagine some us of just need a stable branch no matter the cost, where they can guarantee new bugs aren't added from new features that they don't even use. IMO, D seems in a constant process of keyword and feature assimilation, and D might even be benefited by simply slowing down the pace a little. While I know you treat this simply as a technical issue, it is a psychological issue as well. 1) Big company will never adopt a language which can not /guarantee/ stability. ( or, nonprofessional coder only has time to code , not bug fix ) 2) From the outside, having a compiler constantly add new features + keywords almost guarantee's the compiler won't be stable, and certainly looks like an extremely unstable language from the outside, and therefore an unstable compiler. ~ Clay
Apr 12 2007
next sibling parent reply 0ffh <spam frankhirsch.net> writes:
Clay Smith wrote:
 its stability. We could report bugs, but why report bugs when this 
 fundamental issue can be solved by a simple change of compiler 
 development? Some of us have little time on our hands to develop in D, 
I can't see how any bug is ever going to be fixed, if nobody reports it...
Apr 12 2007
parent Clay Smith <clayasaurus gmail.com> writes:
0ffh wrote:
 Clay Smith wrote:
 its stability. We could report bugs, but why report bugs when this 
 fundamental issue can be solved by a simple change of compiler 
 development? Some of us have little time on our hands to develop in D, 
I can't see how any bug is ever going to be fixed, if nobody reports it...
The bug will never crop up in the first place.
Apr 12 2007
prev sibling parent reply janderson <askme me.com> writes:
Clay Smith wrote:
 Walter Bright wrote:
[snip]
 While I know you treat this simply as a technical issue, it is a 
 psychological issue as well.
[Snip]
 
 ~ Clay
Why not simply release 2 executables? One with -v1 permanently on. No one will be the wiser. LOL. -Joel
Apr 12 2007
parent Clay Smith <clayasaurus gmail.com> writes:
janderson wrote:
 Why not simply release 2 executables?  One with -v1 permanently on.  No 
 one will be the wiser. LOL.
 
 -Joel
It will still have the ref problem.
Apr 12 2007
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 11 Apr 2007 20:01:12 -0400, Walter Bright  =

<newshound1 digitalmars.com> wrote:

 Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is  =
 hard as hell and time consuming. I need time to report bugs. Now I ha=
ve =
 to either restrict use to specific compiler versions, which people  =
 don't always know about and report their issues back to me, until I  =
 remind them they need to downgrade their compiler (which isn't always=
=
 an option if they need bug fixes), or I have to rush to fix my code t=
o =
 workaround such issues and report bugs. If there was a stable branch,=
I =
 could get the code working with the unstable branch at a reasonable  =
 pace.
Please let me know which issues are breaking your code. I'll be sure =
 they get in the test suite so they'll never break again.
Here's the major one: http://d.puremagic.com/issues/show_bug.cgi?id=3D11= 30 - = but not much info. The point is that my code worked on the previous DMD version, and now it= = doesn't compile. Not only this bug, but my code used "ref" as a variable= = name and had some variables declared after "final:" that weren't meant t= o = have the new meaning of final. This code includes -v1 in the compile = script. Should -v1 not treat "ref" as a keyword? Even more painful, should -v1 n= ot = apply "final" to variables? Branching would make these easier. Actually, once I got wind that "final" was applying to variables (even = before the compiler release), I went through my code and tried exluding = = all my variables from final attributes and released such updated code, b= ut = obviously missed a couple. I try to be speedy about making sure my code works that others might rel= y = upon. In some cases so fast that I anticipate it and it's fixed before = it's an issue, such as when I changed my public imports literally to = include "public" way before import became private by default. However, = without branches, this is all very much more difficult, especially when = = there's little I can do to ensure my code will still work. Plus, not everyone is or tries to be so speedy about making sure their = code works, so more and more broken code ends up out there, frustrating = = new and old D users. Any slip up on your part makes it that much harder on those who maintain= = and distribute code. Of course branches don't fix everything, but it's = about maximizing stability and reliability and minimizing potential issu= es. - Chris
Apr 12 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Chris Miller wrote:
 On Wed, 11 Apr 2007 20:01:12 -0400, Walter Bright 
 Please let me know which issues are breaking your code. I'll be sure 
 they get in the test suite so they'll never break again.
Here's the major one: http://d.puremagic.com/issues/show_bug.cgi?id=1130 - but not much info.
Unfortunately, there's not much I can do about it without a failing example.
 The point is that my code worked on the previous DMD version, and now it 
 doesn't compile. Not only this bug, but my code used "ref" as a variable 
 name and had some variables declared after "final:" that weren't meant 
 to have the new meaning of final. This code includes -v1 in the compile 
 script.
 
 Should -v1 not treat "ref" as a keyword?
It was supposed to not do that, but there was a bug in that code. It's been corrected now.
 Even more painful, should -v1 
 not apply "final" to variables? Branching would make these easier.
I'll fix that as well for -v1.
 Any slip up on your part makes it that much harder on those who maintain 
 and distribute code. Of course branches don't fix everything, but it's 
 about maximizing stability and reliability and minimizing potential issues.
I understand how frustrating it can be. I'll try to get an update out today that addresses these.
Apr 12 2007
prev sibling parent reply janderson <askme me.com> writes:
Walter Bright wrote:
 Chris Miller wrote:
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is 
 hard as hell and time consuming. I need time to report bugs. Now I 
 have to either restrict use to specific compiler versions, which 
 people don't always know about and report their issues back to me, 
 until I remind them they need to downgrade their compiler (which isn't 
 always an option if they need bug fixes), or I have to rush to fix my 
 code to workaround such issues and report bugs. If there was a stable 
 branch, I could get the code working with the unstable branch at a 
 reasonable pace.
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
Here's a crazy idea. Why not have all big libraries in some mega test suite. You would only run this test on -v1 just before you release a new version (because it would take so long with 100 odd projects). At the very least you could capture all the compile-time errors that way (and possibly runtime too). Perhaps the D community could figure out a way to get this to you. Maybe they could even provide the test suit and continually add libraries to it themselves until it contains 100+ libraries. It might even be a way to indicate which libraries work in which versions. It would be updated frequently. I guess this could kinda working like that translation system someone mentions a while back, which simply used a massive amount of data to get around the translation problem. -Joel
Apr 14 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to janderson,

 Walter Bright wrote:
 
 Chris Miller wrote:
 
 I know, I know, report bugs. This doesn't cut it. Reporting bugs is
 hard as hell and time consuming. I need time to report bugs. Now I
 have to either restrict use to specific compiler versions, which
 people don't always know about and report their issues back to me,
 until I remind them they need to downgrade their compiler (which
 isn't always an option if they need bug fixes), or I have to rush to
 fix my code to workaround such issues and report bugs. If there was
 a stable branch, I could get the code working with the unstable
 branch at a reasonable pace.
 
Please let me know which issues are breaking your code. I'll be sure they get in the test suite so they'll never break again.
Here's a crazy idea. Why not have all big libraries in some mega test suite. You would only run this test on -v1 just before you release a new version (because it would take so long with 100 odd projects). At the very least you could capture all the compile-time errors that way (and possibly runtime too). Perhaps the D community could figure out a way to get this to you. Maybe they could even provide the test suit and continually add libraries to it themselves until it contains 100+ libraries. It might even be a way to indicate which libraries work in which versions. It would be updated frequently. I guess this could kinda working like that translation system someone mentions a while back, which simply used a massive amount of data to get around the translation problem. -Joel
A "known good vertion" list for dsource would get much of that.
Apr 14 2007
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
janderson wrote:
 Here's a crazy idea.  Why not have all big libraries in some mega test 
 suite.  You would only run this test on -v1 just before you release a 
 new version (because it would take so long with 100 odd projects).  At 
 the very least you could capture all the compile-time errors that way 
 (and possibly runtime too).
I think that dstress is pretty much what you're talking about; the current limitation, of course, is that it focuses on small testcases instead of larger libraries. It seems like various libraries could be checked in (with unitests built-in) and this used as a good automated test suite.
Apr 17 2007
prev sibling next sibling parent reply torhu <fake address.dude> writes:
Chris Miller wrote:
 I'm sure this was brought up in the past, but DMD definitely needs stable  
 and unstable branches.
 
 -v1 doesn't cut it. My code is compiled with -v1 and still breaks with new  
 DMD versions.
 
 Each new DMD version is bug-ridden. This new one 1.011 is pretty bad!
I'm also having the same problems with my D projects. I just added 'doesn't compile with 1.011' to the readme.txt for one project. Since branches has been suggested before, and nothing has happened, I have a suggestion that might mean less extra work for Walter, but still improve the situation a bit: Release a version marked as a beta or release candidate before the final version. If the beta version is accepted by the community (all very informal, what 'accepted' means will have to be Walter's call in each case), it can be renamed, or even just reannounced as a final version. The zip file should at least be renamed, even if the compiler's version number is not changed (in order to avoid the risks of a recompiling and repackaging). If the beta version is deemed too buggy, two things can happen. The first being to just skip the final release for now. And then release a new beta, with the usual mix of bugfixes and new features. The second option is to release a new beta, with only bugfixes, but that might be too close to actual branching to be considered for most cases. Hopefully, people that don't feel like living on the bleeding edge will choose the versions marked as 'final', and stay away from the betas. And people won't excpept any given library or app to compile with a beta version of dmd.
Apr 12 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
torhu wrote:
 I'm also having the same problems with my D projects.  I just added 
 'doesn't compile with 1.011' to the readme.txt for one project.
What doesn't work with 1.011?
Apr 12 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 torhu wrote:
 I'm also having the same problems with my D projects.  I just added 
 'doesn't compile with 1.011' to the readme.txt for one project.
What doesn't work with 1.011?
One issue mentioned last night is that the -H feature of DMD generates output containing "ref" where "inout" was in the original. And apparently there is some sort of problem either parsing the resulting header file or linking against the implementation. I hadn't reported this yet because it being discussed in chat when I logged off for the evening, and I haven't had time to confirm it myself. Sean
Apr 12 2007
parent =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Sean Kelly kirjoitti:
 Walter Bright wrote:
 torhu wrote:
 I'm also having the same problems with my D projects.  I just added
 'doesn't compile with 1.011' to the readme.txt for one project.
What doesn't work with 1.011?
One issue mentioned last night is that the -H feature of DMD generates output containing "ref" where "inout" was in the original.
I reported it and Walter marked it invalid. If inout is going to be deprecated in the future, I guess it's ok that way. I just wanted to point out that the programmer might have different intentions when using 'inout' and 'ref'. Then it would be important for the library user to see the correct keyword. If 'inout' is going to be removed anyway, it may not be worth the effort adding support for both. Just my 2 cents. :)
 And
 apparently there is some sort of problem either parsing the resulting
 header file or linking against the implementation.
Actually it was in rebuild. I didn't notice it didn't yet support the new syntax.
 I hadn't reported
 this yet because it being discussed in chat when I logged off for the
 evening, and I haven't had time to confirm it myself.
 
 
 Sean
Apr 12 2007
prev sibling next sibling parent reply "Serghei Darii" <serge_ds arcor.de> writes:
On Thu, 12 Apr 2007 11:43:44 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:

 torhu wrote:
 I'm also having the same problems with my D projects.  I just added  
 'doesn't compile with 1.011' to the readme.txt for one project.
What doesn't work with 1.011?
Hi Walter, a concrete example (may be it was already reported) when I try to compile DFL lib. First, I have fixed for myself (not waiting for new DFL release) the .ref problem in some files. Second, 'final' for variables in 2-3 files. Third, after that, all compiled correctly in debug mode, but for relase I get: ... Internal error: ..\ztc\gflow.c 1334 .. Yes, ... and this breaks my project. Thank you. Serghei Darii -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Apr 12 2007
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Thu, 12 Apr 2007 13:24:05 -0400, Serghei Darii <serge_ds arcor.de>  
wrote:

 On Thu, 12 Apr 2007 11:43:44 +0200, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 torhu wrote:
 I'm also having the same problems with my D projects.  I just added  
 'doesn't compile with 1.011' to the readme.txt for one project.
What doesn't work with 1.011?
Hi Walter, a concrete example (may be it was already reported) when I try to compile DFL lib. First, I have fixed for myself (not waiting for new DFL release) the .ref problem in some files. Second, 'final' for variables in 2-3 files. Third, after that, all compiled correctly in debug mode, but for relase I get: ... Internal error: ..\ztc\gflow.c 1334 .. Yes, ... and this breaks my project. Thank you. Serghei Darii
I added to http://www.dprogramming.com/dfl.php it includes: Tested with DMD 1.010 and 0.177 Not compatible with DMD 1.011 Please downgrade back to 1.010 at http://www.digitalmars.com/d/changelog.html#new1_010
Apr 12 2007
parent Serghei Darii <serge_ds arcor.de> writes:
Chris Miller wrote:
 On Thu, 12 Apr 2007 13:24:05 -0400, Serghei Darii <serge_ds arcor.de> 
 wrote:
 
 On Thu, 12 Apr 2007 11:43:44 +0200, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 torhu wrote:
 I'm also having the same problems with my D projects.  I just added 
 'doesn't compile with 1.011' to the readme.txt for one project.
What doesn't work with 1.011?
Hi Walter, a concrete example (may be it was already reported) when I try to compile DFL lib. First, I have fixed for myself (not waiting for new DFL release) the .ref problem in some files. Second, 'final' for variables in 2-3 files. Third, after that, all compiled correctly in debug mode, but for relase I get: ... Internal error: ..\ztc\gflow.c 1334 .. Yes, ... and this breaks my project. Thank you. Serghei Darii
I added to http://www.dprogramming.com/dfl.php it includes: Tested with DMD 1.010 and 0.177 Not compatible with DMD 1.011 Please downgrade back to 1.010 at http://www.digitalmars.com/d/changelog.html#new1_010
Yes I know and I did, thank you. I mentioned that because Walter was asking for an example ... had no time to write a bug. Serghei
Apr 12 2007
prev sibling parent torhu <fake address.dude> writes:
Walter Bright wrote:
 torhu wrote:
 I'm also having the same problems with my D projects.  I just added 
 'doesn't compile with 1.011' to the readme.txt for one project.
What doesn't work with 1.011?
Issue 1127 (-v1 doesn't disable the ref and macro keywords), and 1135 (invariant keyword parsing is messed up). The first one is fixed in 1.012, I reported the other one too late it seems.
Apr 12 2007
prev sibling next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
I like this proposal.
And i think that ppl will test the beta. Even ppl on larger projects
will test it, because they *want* a stable version.
Apr 12 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frank Benoit (keinfarbton) wrote:
 I like this proposal.
 And i think that ppl will test the beta. Even ppl on larger projects
 will test it, because they *want* a stable version.
I'm not sure what it buys, since 1.011 obviously breaks things, and I'll fix it as soon as I can.
Apr 12 2007
parent reply torhu <fake address.dude> writes:
Walter Bright wrote:
 Frank Benoit (keinfarbton) wrote:
 I like this proposal.
 And i think that ppl will test the beta. Even ppl on larger projects
 will test it, because they *want* a stable version.
I'm not sure what it buys, since 1.011 obviously breaks things, and I'll fix it as soon as I can.
This is pasted from the readme.txt for my DWT app: --- Versions 0.174 to 1.0 should work. Versions 1.001 to 1.006 do not work properly with DWT apps. Version 1.007 through 1.010 works. Versions 1.011 and 1.012 do not work. --- Maybe I'm taking the wrong approach to this. But I don't know how I could realistically avoid it. Being able to replace it with 'A beta compiler version might not be able to build this project' would be nice.
Apr 12 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
torhu wrote:
 This is pasted from the readme.txt for my DWT app:
 
 ---
 Versions 0.174 to 1.0 should work.
 Versions 1.001 to 1.006 do not work properly with DWT apps.
 Version 1.007 through 1.010 works.
 Versions 1.011 and 1.012 do not work.
 ---
 
 Maybe I'm taking the wrong approach to this.  But I don't know how I 
 could realistically avoid it.
I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.
Apr 12 2007
next sibling parent Aarti_pl <aarti interia.pl> writes:
Walter Bright napisał(a):
 torhu wrote:
 This is pasted from the readme.txt for my DWT app:

 ---
 Versions 0.174 to 1.0 should work.
 Versions 1.001 to 1.006 do not work properly with DWT apps.
 Version 1.007 through 1.010 works.
 Versions 1.011 and 1.012 do not work.
 ---

 Maybe I'm taking the wrong approach to this.  But I don't know how I 
 could realistically avoid it.
I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.
The problem is when another library has something similar in its README.txt and misfortunately you can not find version of DMD which works with BOTH :-| BR Marcin Kuszczak aarti_pl
Apr 13 2007
prev sibling parent reply torhu <fake address.dude> writes:
Walter Bright wrote:
 torhu wrote:
 This is pasted from the readme.txt for my DWT app:
 
 ---
 Versions 0.174 to 1.0 should work.
 Versions 1.001 to 1.006 do not work properly with DWT apps.
 Version 1.007 through 1.010 works.
 Versions 1.011 and 1.012 do not work.
 ---
 
 Maybe I'm taking the wrong approach to this.  But I don't know how I 
 could realistically avoid it.
I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.
The problem wouldn't go away, but it would be greatly reduced. The serious new bugs in 1.011 were discovered almost immediately after the release. Wouldn't it be better if 1.011 was marked as a beta, and not unleashed on the general public until the core D user community had at least verified that their apps and libs build with it? Then you wouldn't need to rush out emergency fixes, like 1.002 through 1.004. You could wait until the dust settles, and maybe get all new bugs fixed in just a single second beta release. 1.012 might also have been a bit premature. I just didn't have time to look into and create a test case and bug report for the invariant parsing issue (bugzilla 1135) until yesterday. That issue seems pretty serious to me, and my app won't build until it's fixed. Not have some kind of separation between bleeding edge and proven stable compiler versions creates a lot of confusion and headaches for everyone. PS. I don't mean to sound like I'm not grateful for what you do, I still love working with D. Just trying to give constructive feedback. ;)
Apr 13 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
torhu wrote:
 Walter Bright wrote:
 torhu wrote:
 This is pasted from the readme.txt for my DWT app:

 ---
 Versions 0.174 to 1.0 should work.
 Versions 1.001 to 1.006 do not work properly with DWT apps.
 Version 1.007 through 1.010 works.
 Versions 1.011 and 1.012 do not work.
 ---

 Maybe I'm taking the wrong approach to this.  But I don't know how I 
 could realistically avoid it.
I don't see any way you can avoid it, regardless of what I do. You should list the compiler versions that the library is guaranteed to work with (and perhaps have a download link for them). That's one reason why all the versions are available for download.
The problem wouldn't go away, but it would be greatly reduced. The serious new bugs in 1.011 were discovered almost immediately after the release. Wouldn't it be better if 1.011 was marked as a beta, and not unleashed on the general public until the core D user community had at least verified that their apps and libs build with it?
How's a post in D.announce "unleashing it on the general public"?? I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a D that works for you, don't upgrade? And if you want to play with new stuff, you upgrade. L.
Apr 13 2007
next sibling parent reply torhu <fake address.dude> writes:
Lionello Lunesu wrote:
 torhu wrote:
 The problem wouldn't go away, but it would be greatly reduced.  The 
 serious new bugs in 1.011 were discovered almost immediately after the 
 release.  Wouldn't it be better if 1.011 was marked as a beta, and not 
 unleashed on the general public until the core D user community had at 
 least verified that their apps and libs build with it?
How's a post in D.announce "unleashing it on the general public"??
The point is that there the announcements and the version numbering is exactly the same for all versions, nothing is marked as being stable or unstable. Look at this page and tell me which versions are stable and which are not. The only way to judge a version's stability is by looking at the changelog of the succeeding version, and how soon after it was released. No other clues are given. http://www.digitalmars.com/d/changelog.html
 
 I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a D 
 that works for you, don't upgrade? And if you want to play with new 
 stuff, you upgrade.
This would be fine if only a single person were to compile any given app or library. And if all apps/libs that each user has would build with the same version. I have currently eleven dmd versions installed, but I wouldn't want users of my libs to need to switch versions if that could be avoided in any way. To be fair, I only use one or two versions at a time, the other are for compatibility testing, etc.
Apr 13 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
torhu wrote:
 Lionello Lunesu wrote:
 torhu wrote:
 The problem wouldn't go away, but it would be greatly reduced.  The 
 serious new bugs in 1.011 were discovered almost immediately after 
 the release.  Wouldn't it be better if 1.011 was marked as a beta, 
 and not unleashed on the general public until the core D user 
 community had at least verified that their apps and libs build with it?
How's a post in D.announce "unleashing it on the general public"??
The point is that there the announcements and the version numbering is exactly the same for all versions, nothing is marked as being stable or unstable. Look at this page and tell me which versions are stable and which are not. The only way to judge a version's stability is by looking at the changelog of the succeeding version, and how soon after it was released. No other clues are given. http://www.digitalmars.com/d/changelog.html
But "stable" and "beta" are relative terms. For some people 1.011 solved their problems so for them 1.011 might be the only stable version.
 I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a 
 D that works for you, don't upgrade? And if you want to play with new 
 stuff, you upgrade.
This would be fine if only a single person were to compile any given app or library. And if all apps/libs that each user has would build with the same version. I have currently eleven dmd versions installed, but I wouldn't want users of my libs to need to switch versions if that could be avoided in any way. To be fair, I only use one or two versions at a time, the other are for compatibility testing, etc.
I think it's very normal to provide a "required compiler version" for any distributed source package. And this is nothing specific to D or DMD: even projects for Visual Studio required either 6.0 or 2002 or 2003 or 2005 or 2005 SP1. Granted, this list doesn't change on a week-to-week basis, but the idea is the same: the users of the sources must know what compiler the sources have been tested with. Of course, as somebody mentioned, you get into a deadlock if you want to use two libraries but one library only compiles with DMD 1.007 and the other needs 1.011. But even then, you can compile with different compilers and just link the stuff together. I like the idea of branching, but it does the merging/backporting of patches involves quite some overhead, possibly too much for a one-man project like DMD. L.
Apr 13 2007
next sibling parent torhu <fake address.dude> writes:
Lionello Lunesu wrote:
 I like the idea of branching, but it does the merging/backporting of 
 patches involves quite some overhead, possibly too much for a one-man 
 project like DMD.
I don't suggest branching, since Walter doesn't seem to want that.
Apr 13 2007
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Lionello Lunesu wrote:

 torhu wrote:
 Lionello Lunesu wrote:
 torhu wrote:
 The problem wouldn't go away, but it would be greatly reduced.  The
 serious new bugs in 1.011 were discovered almost immediately after
 the release.  Wouldn't it be better if 1.011 was marked as a beta,
 and not unleashed on the general public until the core D user
 community had at least verified that their apps and libs build with it?
How's a post in D.announce "unleashing it on the general public"??
The point is that there the announcements and the version numbering is exactly the same for all versions, nothing is marked as being stable or unstable. Look at this page and tell me which versions are stable and which are not. The only way to judge a version's stability is by looking at the changelog of the succeeding version, and how soon after it was released. No other clues are given. http://www.digitalmars.com/d/changelog.html
But "stable" and "beta" are relative terms. For some people 1.011 solved their problems so for them 1.011 might be the only stable version.
 I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a
 D that works for you, don't upgrade? And if you want to play with new
 stuff, you upgrade.
This would be fine if only a single person were to compile any given app or library. And if all apps/libs that each user has would build with the same version. I have currently eleven dmd versions installed, but I wouldn't want users of my libs to need to switch versions if that could be avoided in any way. To be fair, I only use one or two versions at a time, the other are for compatibility testing, etc.
I think it's very normal to provide a "required compiler version" for any distributed source package. And this is nothing specific to D or DMD: even projects for Visual Studio required either 6.0 or 2002 or 2003 or 2005 or 2005 SP1. Granted, this list doesn't change on a week-to-week basis, but the idea is the same: the users of the sources must know what compiler the sources have been tested with. Of course, as somebody mentioned, you get into a deadlock if you want to use two libraries but one library only compiles with DMD 1.007 and the other needs 1.011. But even then, you can compile with different compilers and just link the stuff together.
That won't work either, at least not in that case, as the Object ABI changed with 1.010. The latest stretch of compilers have just been a long line of incompatible releases. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Apr 13 2007
prev sibling next sibling parent Falk-Florian Henrich <schreibmalwieder hammerfort.de> writes:
Am Fri, 13 Apr 2007 13:21:50 +0300 schrieb Lionello Lunesu:

 I think it's very normal to provide a "required compiler version" for
 any distributed source package. And this is nothing specific to D or
 DMD: even projects for Visual Studio required either 6.0 or 2002 or 2003
 or 2005 or 2005 SP1. Granted, this list doesn't change on a week-to-week
 basis, but the idea is the same: the users of the sources must know what
 compiler the sources have been tested with.
I agree that any source package needs to specify some compiler/library requirements. Nevertheless, I do not know of any quality open source software that has dependencies of the type gcc == 3.3.3 libXYZ == 2.3.4 libABC == 1.0.7 Real world packages only specify something like libXYZ >= 2.3.4 If you want people to download and use your software you cannot bother them with awkward dependencies. Sad to say, but at this point of time, D seems to be light years away from that level of interoperability. Falk
Apr 13 2007
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 13 Apr 2007 13:21:50 +0300, Lionello Lunesu wrote:

 But "stable" and "beta" are relative terms. 
Doesn't "stable" mean "no new features - bug fixes only for existing features" and "beta" means "new features are to be expected". -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Apr 13 2007
parent Jesse Phillips <Jesse.K.Phillips+Digitalmars gmail.com> writes:
On Fri, 13 Apr 2007 21:15:25 +1000, Derek Parnell wrote:

 On Fri, 13 Apr 2007 13:21:50 +0300, Lionello Lunesu wrote:
 
 But "stable" and "beta" are relative terms. 
Doesn't "stable" mean "no new features - bug fixes only for existing features" and "beta" means "new features are to be expected".
Actually, Alpha is the new feature stage, Beta is the bug smashing stage, and Stable is supposed to have no major bug and very few bugs. Many times betas end up getting new features.
Apr 13 2007
prev sibling next sibling parent reply Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:
Lionello Lunesu Wrote:
 
 I like the idea of branching, but it does the merging/backporting of 
 patches involves quite some overhead, possibly too much for a one-man 
 project like DMD.
 
 L.
It is true that maintaining two branches involves some more work, but: 1. because a STABLE branch is not supposed to introduce new bugs (in theory), Walter doesn't have to work in a hurry because of possible regressions that create havoc in some users' projects, like he is doing right now. So he can work more peacefully on new features, as people who work with the bleeding edge versions do expect some broken code, and therefore don't complain (but they can report bugs). 2. a STABLE branch offers the chance for people to actually contribute to bug fixing. It's hardly the case with a constantly evolving compiler, as one bug fix may just be out of date in the next version. This discourages people to actually contribute to bug fixing. So this overhead could be compensated at least partly by more involvement of the community members to the improvement of the overall quality of at least the STABLE branch. For everybody, this would be a huge bonus in stability and quality, not only of the compilers, but also of the whole codebase, since library writers can rely on the stable version. The top 5% expert coders will happily work with the bleeding edge evolutions. But for the rest of us, the language may very well be "good enough" right now, but what may prevent people from engaging into large scale projects in D is no longer issues with the expressiveness of the language or the lack of tools (today code::block fills the bill quite nicely) than the uncontrolled risks of incompatibilities between libraries.
Apr 13 2007
parent Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:
Nicolas J. Wrote:

 
 For everybody, this would be a huge bonus in stability and quality, not only
of the compilers, but also of the whole codebase, since library writers can
rely on the stable version. 
 The top 5% expert coders will happily work with the bleeding edge evolutions.
 But for the rest of us, the language may very well be "good enough" right now,
but what may prevent people from engaging into large scale projects in D is no
longer issues with the expressiveness of the language or the lack of tools
(today code::block  fills the bill quite nicely) than the uncontrolled risks of
incompatibilities between libraries.
 
I shall add that the larger the project, the more libraries one usually relies on, and the higher the risks of incompatibilities. It is not uncommon for a 20,000 lines project to rely on 5 or 10 libraries. What is the probability to find 10 libraries compatible with each other and with the latest compilers in the D codebase right now ?
Apr 13 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Lionello Lunesu wrote:
 Of course, as somebody mentioned, you get into a deadlock if you want to 
 use two libraries but one library only compiles with DMD 1.007 and the 
 other needs 1.011.
Unfortunately, I feel that makes the libraries unusable with each other.
 But even then, you can compile with different 
 compilers and just link the stuff together.
That is courting disaster :-(. I'd try that only as a very last resort.
Apr 13 2007
next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
Walter Bright wrote:
 Lionello Lunesu wrote:
 Of course, as somebody mentioned, you get into a deadlock if you want 
 to use two libraries but one library only compiles with DMD 1.007 and 
 the other needs 1.011.
Unfortunately, I feel that makes the libraries unusable with each other.
But that is not necessary the fault of the library code themselves. Perhaps one of them can't use an old compiler because there is a compiler crash, and one can't use a new compiler because it uses a syntax (or keyword) that used to be valid but is now not allowed. If there was "stable" branch of the older compiler, that included the bugfix but not the language change, then both libraries would work together just fine.
Apr 13 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Russell Lewis wrote:
 But that is not necessary the fault of the library code themselves. 
 Perhaps one of them can't use an old compiler because there is a 
 compiler crash, and one can't use a new compiler because it uses a 
 syntax (or keyword) that used to be valid but is now not allowed.  If 
 there was "stable" branch of the older compiler, that included the 
 bugfix but not the language change, then both libraries would work 
 together just fine.
But bugfixes themselves can cause such problems.
Apr 13 2007
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Fri, 13 Apr 2007, Walter Bright wrote:

 Russell Lewis wrote:
 But that is not necessary the fault of the library code themselves. Perhaps
 one of them can't use an old compiler because there is a compiler crash, and
 one can't use a new compiler because it uses a syntax (or keyword) that used
 to be valid but is now not allowed.  If there was "stable" branch of the
 older compiler, that included the bugfix but not the language change, then
 both libraries would work together just fine.
But bugfixes themselves can cause such problems.
Sure, they can. That's not the issue. The issue is that a bug fix is considerably less likely to introduce regressions than new features are. By separating where new features are emerging, you've got a much higher chance of keeping a monotomically increasing in stability release version. If you stick with absolutes can or can't, the debate just can't go anywhere. Nothing is that black or white, it's all about the shades of grey. Later, Brad
Apr 13 2007
parent reply Russell Lewis <webmaster villagersonline.com> writes:
Brad Roberts wrote:
 On Fri, 13 Apr 2007, Walter Bright wrote:
 But bugfixes themselves can cause such problems.
Sure, they can. That's not the issue. The issue is that a bug fix is considerably less likely to introduce regressions than new features are. By separating where new features are emerging, you've got a much higher chance of keeping a monotomically increasing in stability release version.
Let me say something here about "monotonically increasing stability." IMHO, this is not an absolute requirement of a "stable" release. At least in my company, we don't pick up new tools (compilers, etc.) without putting in some test on them. If I was using dmd for work, for instance, I wouldn't put a new version of the compiler to production use until (at least) the new DStress report had come out, and I had done a test build with the compiler on my code. (Plus run a few quick regression tests on my code built with the new compiler.) So if there are new bugs in a new compiler, I simply never pick it up. That's unfortunate, but not terminal. I know that some here will disagree, but to me the essence of a "stable" branch is not bug-free compilers every time, but instead a reasonable expectation that I will eventually get my bugs fixed without having to simultaneously pick up new language changes.
Apr 13 2007
parent Brad Roberts <braddr puremagic.com> writes:
Russell Lewis wrote:
 Brad Roberts wrote:
 On Fri, 13 Apr 2007, Walter Bright wrote:
 But bugfixes themselves can cause such problems.
Sure, they can. That's not the issue. The issue is that a bug fix is considerably less likely to introduce regressions than new features are. By separating where new features are emerging, you've got a much higher chance of keeping a monotomically increasing in stability release version.
Let me say something here about "monotonically increasing stability." IMHO, this is not an absolute requirement of a "stable" release. At least in my company, we don't pick up new tools (compilers, etc.) without putting in some test on them. If I was using dmd for work, for instance, I wouldn't put a new version of the compiler to production use until (at least) the new DStress report had come out, and I had done a test build with the compiler on my code. (Plus run a few quick regression tests on my code built with the new compiler.) So if there are new bugs in a new compiler, I simply never pick it up. That's unfortunate, but not terminal. I know that some here will disagree, but to me the essence of a "stable" branch is not bug-free compilers every time, but instead a reasonable expectation that I will eventually get my bugs fixed without having to simultaneously pick up new language changes.
Of course it's not an absolute requirement. Achieving it would require a perfect test suite which by necessity would mean that there's no bugs. I purposely said 'much higher chance of keeping a...' to indicate that's the goal of release branch.
Apr 13 2007
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Walter Bright wrote:
 Russell Lewis wrote:
 But that is not necessary the fault of the library code themselves. 
 Perhaps one of them can't use an old compiler because there is a 
 compiler crash, and one can't use a new compiler because it uses a 
 syntax (or keyword) that used to be valid but is now not allowed.  If 
 there was "stable" branch of the older compiler, that included the 
 bugfix but not the language change, then both libraries would work 
 together just fine.
But bugfixes themselves can cause such problems.
Sort of. Obviously, bugfixes sometimes are buggy - that's just part of life. Fix 'em as you find 'em. But a bugfix shouldn't break code that (from the perspective of the user) seemed to work in the past. If so, then you are doing more than fixing bugs - you are now changing the language, and the "stable" release shouldn't do that unless there is a Very Good Reason. (I know, there are pathological cases where the user is depending on the buggy output of the compiler, and when you fix it, he complains...but those users are much less interesting to me than the well-informed, conservative programmer, with a large project, who needs a bugfix but who can't pick up the latest changes to the language.)
Apr 13 2007
prev sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:
 Lionello Lunesu wrote:
 
 Of course, as somebody mentioned, you get into a deadlock if you want 
 to use two libraries but one library only compiles with DMD 1.007 and 
 the other needs 1.011.
Unfortunately, I feel that makes the libraries unusable with each other.
 But even then, you can compile with different compilers and just link 
 the stuff together.
That is courting disaster :-(. I'd try that only as a very last resort.
Hmm. Then nobody should distribute compiled libraries. The -H switch just became obsolete.
Apr 15 2007
prev sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
Lionello Lunesu wrote:
 How's a post in D.announce "unleashing it on the general public"??
 
 I'd say: if it ain't broke, don't 'fix' it. Meaning that if you have a D 
 that works for you, don't upgrade? And if you want to play with new 
 stuff, you upgrade.
The problem is that this doesn't work in the real world with real projects. Imagine that you have a gigantic project (100,000 lines or more), and late in the game you stumble across some small (but important) bug. You work on it, and finally realize that the root cause is in the compiler: it is producing incorrect code, or whatever. You post a bug, and the response is, "This bug was fixed in version 1.2.3.4." Problem is, 1.2.1.2 introduced a major change to the language which will break 1000s of lines of your code. Or, worse yet, there have been many small changes to the language...and you don't know if they would break your code or not. If you pick up the new compiler, you must first test build the entire project, then start your test over, pretty much from scratch, in order to confirm that nothing is subtly broken. This isn't going to happen. So what do you do now? Do you rewrite your whole project so that you can pick up the new compiler? Do you find some sort of hackish workaround in your code to avoid the bug? I face this problem all the time at work. We have released a large, expensive product to the field. We have customers who hit bugs (and our QA department, while reduced in size, is still active and finding new bugs). We are required to fix these bugs and periodically release new versions of the microcode...but we must never break what "works" in the field. Breakage is the Cardinal Sin of my development group. Every new (or changed) feature in D is potentially Breakage, which is why, IMHO, somebody (perhaps not Walter) needs to maintain a "stable" branch. Russ
Apr 13 2007
next sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Sorry for using the term "real world," I hate it when people talk that 
way.  All I am trying to say is that while the current release style for 
dmd is good for some things (I love to use D at home), it is 
insufficient to support large-scale, high-requirement projects, like 
what I have to do at work.

Russ
Apr 13 2007
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Russell Lewis wrote:
 So what do you do now?  Do you rewrite your whole project so that you 
 can pick up the new compiler?  Do you find some sort of hackish 
 workaround in your code to avoid the bug?
Or you could try a different compiler all-together :) What do you do if you'd get a ICE in Visual Studio for example? Trust me, I got plenty, and each time I just kept rewriting and reordering the code until it worked. L.
Apr 15 2007
prev sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Thu, 12 Apr 2007 05:20:27 -0400, torhu <fake address.dude> wrote:

 I'm also having the same problems with my D projects.  I just added  
 'doesn't compile with 1.011' to the readme.txt for one project.

 Since branches has been suggested before, and nothing has happened, I  
 have a suggestion that might mean less extra work for Walter, but still  
 improve the situation a bit:  Release a version marked as a beta or  
 release candidate before the final version.

 If the beta version is accepted by the community (all very informal,  
 what 'accepted' means will have to be Walter's call in each case), it  
 can be renamed, or even just reannounced as a final version.  The zip  
 file should at least be renamed, even if the compiler's version number  
 is not changed (in order to avoid the risks of a recompiling and  
 repackaging).
This might be a decent compromise. At least small oversights can be fixed up without affecting regular D users. Beta testers (probably those testing their libraries) can try things out and report any issues. There could be a standard beta time, such as one week after the latest beta release, before the public version and release announcement. Beta tests could possibly only be accessible via a new separate page and are not posted to the announce NG. Perhaps there could be a separate digitalmars.D.beta group for that instead, also for discussing beta issues. - Chris
Apr 12 2007
parent Don Clugston <dac nospam.com.au> writes:
Chris Miller wrote:
 On Thu, 12 Apr 2007 05:20:27 -0400, torhu <fake address.dude> wrote:
 
 I'm also having the same problems with my D projects.  I just added 
 'doesn't compile with 1.011' to the readme.txt for one project.

 Since branches has been suggested before, and nothing has happened, I 
 have a suggestion that might mean less extra work for Walter, but 
 still improve the situation a bit:  Release a version marked as a beta 
 or release candidate before the final version.

 If the beta version is accepted by the community (all very informal, 
 what 'accepted' means will have to be Walter's call in each case), it 
 can be renamed, or even just reannounced as a final version.  The zip 
 file should at least be renamed, even if the compiler's version number 
 is not changed (in order to avoid the risks of a recompiling and 
 repackaging).
This might be a decent compromise. At least small oversights can be fixed up without affecting regular D users. Beta testers (probably those testing their libraries) can try things out and report any issues. There could be a standard beta time, such as one week after the latest beta release, before the public version and release announcement. Beta tests could possibly only be accessible via a new separate page and are not posted to the announce NG. Perhaps there could be a separate digitalmars.D.beta group for that instead, also for discussing beta issues. - Chris
Why not simply add a line to the download page which states 'last stable version' and points to the previous download. So that newcomers to D don't download a half-hour old compiler and find that popular libraries won't compile. (a PR disaster). BTW, to be fair, g++ 4.0 was a mess, with more codegen bugs than I've seen in any DMD release -- and that's a much higher profile project, with a much bigger team than DMD does.
Apr 12 2007
prev sibling next sibling parent reply David Ferenczi <raggae ferenczi.net> writes:
I also second this.

Walter, please don't to address (just) the concrete bugs arose with the last
release, but the root of the problem.

And it is definitely the development model. D is a moving target. We all
love this language, but we need a stable branch with fast and frequent
bugfixes.

Please listen to your users.

Reagrds,
David
Apr 12 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
David Ferenczi wrote:
 I also second this.
 
 Walter, please don't to address (just) the concrete bugs arose with the last
 release, but the root of the problem.
 
 And it is definitely the development model. D is a moving target. We all
 love this language, but we need a stable branch with fast and frequent
 bugfixes.
 
 Please listen to your users.
The problem is that one cannot just do bugfixes without running the risk of breaking things. The final thing was an effort to fix the existing buggy final behavior.
Apr 12 2007
parent Russell Lewis <webmaster villagersonline.com> writes:
Walter Bright wrote:
 David Ferenczi wrote:
 I also second this.

 Walter, please don't to address (just) the concrete bugs arose with 
 the last
 release, but the root of the problem.

 And it is definitely the development model. D is a moving target. We all
 love this language, but we need a stable branch with fast and frequent
 bugfixes.

 Please listen to your users.
The problem is that one cannot just do bugfixes without running the risk of breaking things. The final thing was an effort to fix the existing buggy final behavior.
I understand what you're saying, Walter, but I don't think that what you're saying is totally fair. As I see it, there are several different types of fixes/changes that one makes in a project: 1) Fixes to resolve things that are clearly bugs, like incorrect code generation, compiler crashes, etc. 2) Fixes to correct "misfeatures." These are things that are currently functional, but may not be working according to the spec (such as final) 3) New features What I think people are asking is that you branch the code so that the stable branch only gets type (1) fixes. It might, rarely, get type (2) fixes, but only after careful consideration and warning to the community BEFORE you implement it. The point is: the "stable" branch should not be changing anything which a user might reasonably think is "working correctly." Even if you think it is a misfeature, or it doesn't match the spec, you generally leave it as-is, and simply post a README with the "stable" branche which lists these lingering issues. I'm not saying that you have any particular obligation to do this, Walter...it is certainly within your perogative to say no. But at this point in the lifetime of D, doesn't *somebody* have to do it?
Apr 12 2007
prev sibling next sibling parent reply Dan <murpsoft hotmail.com> writes:
Walter Bright Wrote:
 The test suite is run before every new release. If things break with a 
 new release, it is because the case isn't reflected in the test suite. 
 Every fixed bug goes in to the test suite. For example, Kris posted two 
 things that broke with the 1.011 update. Both are fixed now, and both 
 are now in the test suite. They'll stay fixed.
 
 Over time, the suite has a ratchet effect, with things getting better 
 and better. I've been using that system for decades with the C++ 
 compiler, and it's pretty rare for an update to break anything.
 
 But if bugs aren't reported, then they don't get fixed, and the test 
 case never winds up in the test suite.
 
 The only way to get a stable system is to report bugs, fix them, and put 
 the cases in the test suite. I tend to put priority on fixing things 
 that break existing code; I know how maddening that can be.
Hmm... I actually like the method to his madness. : ) If we provide a means by which D can be thoroughly tested through and through, then each version that he writes must conform to that test? What if we were to then write a test suite that enforced proveable conformance to the D specification for 1.0? Evolving a truly complete test suite seems more sensible than endlessly adding bug-able examples...
Apr 13 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan schrieb am 2007-04-13:
[snip]
 What if we were to then write a test suite that enforced provable conformance
 to the D specification for 1.0?  Evolving a truly complete test suite seems 
 more sensible than endlessly adding bug-able examples...
You are welcome to do so. However the only sensible way to do so would be to use formal specification to generate the tests. While this is a relatively trivial task for the syntax tests (especially the no-compile target) runtime tests will require a serious amount of work. DStress[1] at least (don't know about Walter's test suite) contains quite a number of pro-active test cases. I simply haven't gotten around to add tests for the post DMD-1.004 features. Another problem is the processing power required to run those tests. e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run in 32 different configuration ("-O", "-inline", "-O -inline", etc.) resulting in 213324 tests. In total that resulted in ca. 214000 compiler invocations, 138000 linker invocations and ca. 137500 executions of newly generated executables. Thomas [1] http://dstress.kuehne.cn -----BEGIN PGP SIGNATURE----- iD8DBQFGIK11LK5blCcjpWoRAtdiAJ4zftd2EdejPrH/9d4H4qwNwcVJTwCfY10D I7E+6myEksiY/zwpV0ekN2U= =BOPN -----END PGP SIGNATURE-----
Apr 14 2007
next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Thomas Kuehne wrote:
 [...]
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.
 [...]
C'mon, Thomas! Quit making excuses and overclock that Commodore 64 already!! Dave
Apr 14 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David B. Held schrieb am 2007-04-14:
 Thomas Kuehne wrote:
 [...]
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.
 [...]
C'mon, Thomas! Quit making excuses and overclock that Commodore 64 already!!
My test system is Turion 64 clocked at 1.6GHz with 2GB RAM. However the tests only run with "nice -n 18" in the background thus donating hardware might help. And yes, the testsuite has no trouble to keep all cores in a N-cpu system (with 1 <= N <= 6000) busy. ;-P Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFGIS/yLK5blCcjpWoRAkfCAJ9IlkaaS1Pfhqmt9RpYND8txpbdTQCgoKYc TXW3uGunf+hhBuO4JPOWD0M= =jRXT -----END PGP SIGNATURE-----
Apr 14 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Thomas,

 My test system is Turion 64 clocked at 1.6GHz with 2GB RAM. However
 the
 tests only run with "nice -n 18" in the background thus donating
 hardware
 might help. And yes, the testsuite has no trouble to keep all cores
 in a N-cpu system (with 1 <= N <= 6000) busy.
 ;-P
 
 Thomas
BTW how long does it take dstress to run? I ask because I have a lexer that is able to lex almost all of the compile branch (~4700 files) in just over a minute. I'm wondering how this compares to DMD.
Apr 14 2007
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BCS schrieb am 2007-04-14:
 BTW how long does it take dstress to run? I ask because I have a lexer that 
 is able to lex almost all of the compile branch (~4700 files) in just over 
 a minute. I'm wondering how this compares to DMD.
I've send you a stubbed DMD-1.011 frontend (too large for posting here). Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFGIdK1LK5blCcjpWoRAtLUAJ0fP7XTJSSwo2Cnk9IpJzXA8TqrtgCgipSs sc9JIKFjyB531b60LQlsERk= =Hlvc -----END PGP SIGNATURE-----
Apr 15 2007
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Thomas Kuehne wrote:
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.
How long does it take for all tests to complete? Big difference between GDC/DMD? L.
Apr 15 2007
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lionello Lunesu schrieb am 2007-04-16:
 Thomas Kuehne wrote:
 Another problem is the processing power required to run those tests.
 e.g. the DMD-1.009 run contained 6801 test cases. Most of them were run
 in 32 different configuration ("-O", "-inline", "-O -inline", etc.)
 resulting in 213324 tests. In total that resulted in ca. 214000 compiler
 invocations, 138000 linker invocations and ca. 137500 executions of
 newly generated executables.
How long does it take for all tests to complete? Big difference between GDC/DMD?
If the testsuite is the only running application and neglection dead locks: ~ 25 hours for DMD, ~ 36 hours for GDC Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFGIz9OLK5blCcjpWoRAkDcAJ9aY6qITQvtED3Ox6j+3+QiXH4wWACgmPad lWbczCH+9Jfzg2QZHbBtrzc= =J6/U -----END PGP SIGNATURE-----
Apr 16 2007
parent reply Dan <murpsoft hotmail.com> writes:
Thomas Kuehne Wrote:
 How long does it take for all tests to complete? Big difference between 
 GDC/DMD?
If the testsuite is the only running application and neglection dead locks: ~ 25 hours for DMD, ~ 36 hours for GDC
Holy moley batman! I didn't know D had enough source to take that long to do *anything* to it. I could almost manually retype my entire scripting engine in that much time!
Apr 16 2007
parent reply Sean Kelly <sean f4.ca> writes:
Dan wrote:
 Thomas Kuehne Wrote:
 How long does it take for all tests to complete? Big difference between 
 GDC/DMD?
If the testsuite is the only running application and neglection dead locks: ~ 25 hours for DMD, ~ 36 hours for GDC
Holy moley batman! I didn't know D had enough source to take that long to do *anything* to it. I could almost manually retype my entire scripting engine in that much time!
Sounds like D needs a DDStress client, kinda like SETI Home ;-) Sean
Apr 16 2007
parent Pragma <ericanderton yahoo.removeme.com> writes:
Sean Kelly wrote:
 Dan wrote:
 Thomas Kuehne Wrote:
 How long does it take for all tests to complete? Big difference 
 between GDC/DMD?
If the testsuite is the only running application and neglection dead locks: ~ 25 hours for DMD, ~ 36 hours for GDC
Holy moley batman! I didn't know D had enough source to take that long to do *anything* to it. I could almost manually retype my entire scripting engine in that much time!
Sounds like D needs a DDStress client, kinda like SETI Home ;-) Sean
Would that work? 0) download client 1) client runs and syncs with stress-test repository 1.1) client syncs compiler distribution(s) for needed tests 1.2) client gets list of incomplete test cases 1.3) client syncs stress-test code for needed test cases 2) client runs needed tests 3) client reports results 4) sleep while not idle 5) (system idle) loop to 1 That might work a treat for performance testing of discrete code samples, if nothing else. -- - EricAnderton at yahoo
Apr 16 2007
prev sibling next sibling parent Dan <murpsoft hotmail.com> writes:
janderson Wrote:

 Clay Smith wrote:
 Walter Bright wrote:
[snip]
 While I know you treat this simply as a technical issue, it is a 
 psychological issue as well.
[Snip]
 
 ~ Clay
Why not simply release 2 executables? One with -v1 permanently on. No one will be the wiser. LOL.
Indeed, just post a link to 1.05 with the -v1 switch on, and label the link "Stable Release" and never take it down. : ) That's pretty much all people are asking for - is that stable release link they can have people click on that won't change. If a bug is identified in that stable release, don't fix it, just document it. Later, when you get up to 1.2, change the link to "Stable Releases" and release 1.2.3 or whatnot. Problem solved?
Apr 13 2007
prev sibling next sibling parent eao197 <eao197 intervale.ru> writes:
There were many right words about an important role of stable branches of  
D compiler in big ("real-world") projects. I can understand the people who  
use D for long time and have big amount of code, but I'm in the different  
situation -- I just have started my switching from C++ to D. And for me  
the changes in D after v.1.000 are much more valueable then the fact of  
passing 'v.1.000 milestone'. IMHO, the next D version, 2.0 with  
const/final/invariant and AST macroses, can make D more powerful and  
attractive language. So I want see high speed of D evolution now and such  
speed of language changing makes separation of D to 'stable' and  
'unstable' versions undesirable at the current time (from my point of  
view). But that question is going to be actual when D will reach some  
limit in his evolution. When Walter Bright will have said: "There isn't  
any new feature I want add to D". That will be point of the language  
stabilisation.

So I want to ask Walter:

Do you see any visible limit in D evolution? Do you known the moment after  
that you will say: "It's time to stop add new features to languages and  
start collect user expirience after several years of stable language  
version usage"?

-- 
Regards,
Yauheni Akhotnikau
Apr 14 2007
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
DMD v1.012 seems good; I'm not having the issues I experienced that were  
introduced in v1.011.

I also decided to test my code that was having some memory garbage  
collected too early if I didn't use std.gc.setV1_0() and the problem seems  
fixed now (without the v1.0 call). I haven't been testing this particular  
issue with all the recent releases, so it was probably fixed a few  
versions ago.

"Bug ridden" isn't so accurate, as I previously phrased; sorry about that.  
I was actually referring to the earlier 1.0 versions, and then this v1.011  
released with breaking issues. DMD v1.012 seems considerably more stable  
than those earlier 1.0 versions.

I still think something needs to be done to minimize instability, even if  
it's just the previously proposed one-week-early prerelease to catch  
obvious slip-ups. A prerelease/beta page can have a specific date that it  
will go public, so users know exactly when they have to report their  
issues without it being too late. Any reported and fixed issues will cause  
the prerelease to be replaced and the date will probably be reset to be  
another week from that day. An upside to the prereleases is you don't need  
to keep them available beyond their prerelease lifetime.

How the current dmd.zip is only referring to 1.010 is not enough, although  
I appreciate the effort. A lot of people, including myself, download from  
the changelog and/or expect to get the top version. I think a separate  
branch or prerelease will at least put people into a different mindset  
about new versions, because there will be a clear separation.

Also, the prereleases can be used to try out new stuff, which can say  
there is no planned release time. E.g. that regex syntax that popped up  
for a version or two.

- Chris
Apr 14 2007
prev sibling parent reply Nicolai Waniek <no.spam thank.you> writes:
Hello Guys,
At the moment I'm not using D because I have no project that depends on it
(there is just a small python project in my spare time currently) but I'm
following all the discussions here about "branching" and "documentation" and
"buggy versions" and all the stuff and having professional experience with a
huge project (>1.500.000 LOC) having some problems like that and having to
integrate better bug-fixing mechanisms and so on, I would like to participate in
the discussion this time and provide some knowledge I have, though I don't know
if it suits to a 1-man-project like D is, but here are my thoughts:



I. Branching and why it is good - but more work to do

I.1 The long story

Our project was huge and there were lots of bugs in it because it based on an
old project and we couldn't dump it and begin at zero. Due to managment
problems, the software was released early and we had no "betas" - it event went
so far I was ashamed to release a version in such an unstable state. Long story
short, we Developers had to grab the steering wheel and provide more stable
versions because management just ignored what we were saying. So the first step
was to simply branch the project. We were a very small team so I know why Walter
just does not to take this step: It involves everyone in much work. The "old
branch" was just for bugfixing purposes sharing some code with the "new branch"
that got all the new features. Our customers liked it that way because though
they had to wait longer for a new feature, the version they used got stable. We
even branched it again, so that we had three branches:

1. stable, release build (called "release")
2. unstable with few new features to be tested ("beta")
3. _very_ unstable with all the new shiny things we could think of. ("unstable")

The first one, the stable branch, was that version of the software our customers
used. They got a new version about every 4 weeks.
The second version was the one with bugfixes for the "stable" on to be tested
yet and with few features that we thought were stable enough to be but from
branch "unstable" to this one.
The third branch was the one with all the new features, but heavily unstable and
- of course - untested (because developer's always exactly know what to do to
don't get exceptions, though this might not be intentionally done!).

This was lot's of work to be done, because (as mentioned above) we were a very
small team. Everyone had to do some bugfixing for the stable one. These fixes
where checked into branch "beta". When a feature of branch "unstable" was
finished and succeeded our tests, it was moved to branch "beta". "beta-versions"
were released very often because our software was used in our company, so we had
 about 20 beta-testers and hotfixes for the beta version could be done quickly
and - even better - deployed quickly to our beta-testers (it usually took less
than an hour when there was a nasty bug in the beta to be fixed). Nevertheless,
when the new features that were included into the beta were somewhat stable, we
called in a "feature freeze" and there were no changes to the beta anymore than
bugfixes for about 1-2 weeks. When this timespan passed by, the beta was
hardened enough to become the new "stable" version.

In the long run, branching was hard to do in the beginning, but it improved
heavily the stability of our software and even improved development speed
because we could concentrate on the task to be accomplished and not on "oh, when
I do this, it might break that" (because we knew a new feature won't be released
tomorrow ;) ).


I.2 How to adopt to D?

Well this might be a nice story but you might ask "what the heck does this have
 to do with D"? Your question is legitimate, but it shows how Walter could
change its development style, even when he's the only developer:

- Have a "stable" branch, that is, the one everyone should use for their real
world projects.
- Have a "beta" branch where all the bugfixes for the stable branch are
incorporated into and new features you think they are stable enough to be
published
- Have an "unstable" branch were you can doodle around with everything you ever
wanted to do with the D compiler ;) When you think, feature "x" is worth it,
move it to D.
- Think of "release cycles", like "there's a bugfixed and labeled "stable" D
compiler every 3 weeks". This could be done this way: 2 weeks for new features
to be pushed into "beta", then feature freeze and afterwards one week of "beta
testing" (and I bet there are lots of D users that will participate!). During
this week, you might bugfix the nastiest bugs and then release the stable one. I
don't know how much time you have, so you might change the times from 3 weeks to
4,5,... whatever.

You don't need real branches for that, you may even just copy the source files
from one directory to another, but having a backend like SVN doing it will save
you lots of work to be done (e.g. you could share some source files through all
branches when you're certain that they won't get changed).




II. Documentation

In my opinion, documentation could be done by the community. There should be
more examples, tutorials, or whatever bundled with D when downloading so a user
does not have to navigate to 4dwiki, or whatever. This could be done by the
community itself, so no work for you: If someone has the urge to write a
tutorial/help file, just do it and the community could rate it. Simple example:
Someone writes an article about CTFE in D. The community has the possibility to
rate it from 0 (bad) - to 5 (superb). After two weeks, the article has an
overall rate of 4.3, so it's not that bad and you'll incorporate it into the
help files. Something like this... but one has to think of a number an article
has to achieve to become part of the help files (e.g. 3.75 or 4).



These are just some ideas and my opinion about "how one might do things". so
take them up and improve them, where you think something could be done better/in
another way and let us know. :)

(and with "you" I don't only address Walter, but everyone)


best regards,
Nicolai
Apr 15 2007
parent reply Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:
Nicolai Waniek Wrote:
 You don't need real branches for that, you may even just copy the source files
 from one directory to another, but having a backend like SVN doing it will save
 you lots of work to be done (e.g. you could share some source files through all
 branches when you're certain that they won't get changed).
Unfortunately, because it doesn't keep track of history, SVN is not very good at merging, so that it gives a little more work for the maintenance of several parallel branches, even though it still reduces the work of reporting patches by maybe 80%. More powerful tools like darcs and mercurial reduce the number of merge conflicts (and therefore manual work) greatly. darcs has a very interesting concept of dependencies between patches that allow to undo a patch easily: i.e it is possible to remove a patch and the SCM will remove all the patches that were dependent on it. Decentralized SCM like those ones are better suited to open source software than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to connect to the central server to be able to work. In this model, each developer has a complete local copy of the central repository, so that he can work offline. He only connects to it to synchronize, so this model scales better than the centralized model. A google tech talk of presentation of mercurial: http://video.google.com/videoplay?docid=-7724296011317502612 (but of course, it's up to Walter to decide what he is up to...)
Apr 15 2007
parent reply Leandro Lucarella <llucax gmail.com> writes:
Nicolas J., el 15 de abril a las 13:51 me escribiste:
 Nicolai Waniek Wrote:
 You don't need real branches for that, you may even just copy the source files
 from one directory to another, but having a backend like SVN doing it will save
 you lots of work to be done (e.g. you could share some source files through all
 branches when you're certain that they won't get changed).
Unfortunately, because it doesn't keep track of history, SVN is not very good at merging, so that it gives a little more work for the maintenance of several parallel branches, even though it still reduces the work of reporting patches by maybe 80%. More powerful tools like darcs and mercurial reduce the number of merge conflicts (and therefore manual work) greatly. darcs has a very interesting concept of dependencies between patches that allow to undo a patch easily: i.e it is possible to remove a patch and the SCM will remove all the patches that were dependent on it. Decentralized SCM like those ones are better suited to open source software than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to connect to the central server to be able to work. In this model, each developer has a complete local copy of the central repository, so that he can work offline. He only connects to it to synchronize, so this model scales better than the centralized model.
The problem with darcs it's it doesn't scale very well (because of implementation issues, they say). I love darcs for small projects, but (sadly) it's not really suitable for big ones yet. Another great (distributed) SCM is git, done by Linus Tolvards for maintaing the Linux kernel (a really big project, as you know, so it scales by design). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ .------------------------------------------------------------------------, \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / '--------------------------------------------------------------------' Soñé que tenia un caballo Que me trataba mejor que vos Tenia tan buena onda con ella Era mi yegua, mucho mas que vos
Apr 15 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Leandro Lucarella wrote:
 Nicolas J., el 15 de abril a las 13:51 me escribiste:
 Nicolai Waniek Wrote:
 You don't need real branches for that, you may even just copy the source files
 from one directory to another, but having a backend like SVN doing it will save
 you lots of work to be done (e.g. you could share some source files through all
 branches when you're certain that they won't get changed).
Unfortunately, because it doesn't keep track of history, SVN is not very good at merging, so that it gives a little more work for the maintenance of several parallel branches, even though it still reduces the work of reporting patches by maybe 80%. More powerful tools like darcs and mercurial reduce the number of merge conflicts (and therefore manual work) greatly. darcs has a very interesting concept of dependencies between patches that allow to undo a patch easily: i.e it is possible to remove a patch and the SCM will remove all the patches that were dependent on it. Decentralized SCM like those ones are better suited to open source software than centralized SCM (CVS, SVN, Clearcase...) because one doesn't need to connect to the central server to be able to work. In this model, each developer has a complete local copy of the central repository, so that he can work offline. He only connects to it to synchronize, so this model scales better than the centralized model.
The problem with darcs it's it doesn't scale very well (because of implementation issues, they say). I love darcs for small projects, but (sadly) it's not really suitable for big ones yet. Another great (distributed) SCM is git, done by Linus Tolvards for maintaing the Linux kernel (a really big project, as you know, so it scales by design).
Grr. Why do we have to have *four* credible competitors to svn all the sudden? (Mercurial, Git, Darcs, Monotone) When SVN came out it was a no brainer. Better than CVS: check. Anything else better than CVS and still free? Nope. Ok, SVN it is then! But now we have to deal with *four* credible challengers to SVN. Can somebody please tell me which three of those projects are destined for the also-ran bucket so I don't have to waste any time learning them? [Mostly kidding -- choice is great, competition is great. I just wish there were one that blew the others so totally out of the water that it would be a no-brainer] :-)
Apr 15 2007
prev sibling parent reply Nicolas J. <Nicolas.J. lolrofl.fakeaddress.com> writes:
Leandro Lucarella Wrote:

 The problem with darcs it's it doesn't scale very well (because of
 implementation issues, they say). I love darcs for small projects, but
 (sadly) it's not really suitable for big ones yet.
 
 Another great (distributed) SCM is git, done by Linus Tolvards for
 maintaing the Linux kernel (a really big project, as you know, so it
 scales by design).
 
 -- 
Yes. And in fact, browsing the darcs repository online (which I suppose is managed by darcs) is a pretty painful experience. http://abridgegame.org/cgi-bin/darcs.cgi/darcs/ git is hardly an option beacuse it is non-portable (it takes advantages of optimizations for the Libux kernel, from what I gather, so it's not going to be ported soon), and it has some usability issues due to design choices of its author ("renaming files is not important"). I believe mercurial would be a much better option, as it is said to scale very well. And it also has the Clearcase-like merge with history. Anyway, this is probably not the right moment to continue discussing things like this.
Apr 15 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Nicolas J. wrote:
 Leandro Lucarella Wrote:
 
 The problem with darcs it's it doesn't scale very well (because of
 implementation issues, they say). I love darcs for small projects, but
 (sadly) it's not really suitable for big ones yet.

 Another great (distributed) SCM is git, done by Linus Tolvards for
 maintaing the Linux kernel (a really big project, as you know, so it
 scales by design).

 -- 
Yes. And in fact, browsing the darcs repository online (which I suppose is managed by darcs) is a pretty painful experience. http://abridgegame.org/cgi-bin/darcs.cgi/darcs/ git is hardly an option beacuse it is non-portable (it takes advantages of optimizations for the Libux kernel, from what I gather, so it's not going to be ported soon), and it has some usability issues due to design choices of its author ("renaming files is not important"). I believe mercurial would be a much better option, as it is said to scale very well. And it also has the Clearcase-like merge with history. Anyway, this is probably not the right moment to continue discussing things like this.
That was my impression about git too, but apparently current devs are more interested and open about win32 issues. Also you can now get a precompiled git for windows via Cygwin whereas before the answer I got was something like "yeh, you should be able to compile it on Windows with cygwin, no prob". The inkscape devs have pretty much decided to go with Git. I cried "noooooo" like you, because my experience had been that Git was for Linux and Unix. Period. End of story. But they say it's not so. And Git is the only SCM to have Google SoC projects, so that seems like it says something about how much they've got their act together. Plus it does have that whole Linux seal of approval, so it's not going away any time soon. The UI issues I don't know much about, but I gather that's what 'cogito' is for -- to put a user-friendly svn-like face on git. Now may not be the best time to discuss it for D, per-se, but I'm tired of not being able to do commits when I'm home or traveling, and I'm ready to switch to one of these fancy distributed thingamajigs. I just can't tell which one because none of those projects will come right out and say honestly "<Project> -- We're not as good as <X>,<Y>, and <Z>, but we're usable!" Like the darcs performance thing. Never heard that before. But that plus the idea being kooky to begin with (source code control based on "quantum theory" -- uh, yeh, whatever) sound like good enough reasons to drop it off the list. :-) Now what about the other two? :-) Gaim (now Pidgin) just announced a move to Monotone, and I assume someone looked carefully into that choice. Here's something that would matter to me -- which one has the best tools for migrating from svn? Anyone know? --bb
Apr 15 2007