www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos - breaking existing code

reply Walter Bright <newshound2 digitalmars.com> writes:
Just for fun, I've decided to try and get MicroEmacs in D added to the dub 
registry. The last time it compiled was 2 years ago.

I wound up with at least a dozen references to Phobos names that have 
disappeared. No corrective action was indicated, just "undefined symbol". I
have 
to go refigure out what the code was trying to do, and go poking through the 
Phobos documentation to see what will work today.

I know there's been a lot of "break my code" advocacy lately, but this code was 
only 2 years old.

I fully understand how unfriendly this is to users and how discouraging it can 
be to have their recently working code shattered and scattered. We need to do a 
lot better.
Nov 28 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 15:33:51 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Just for fun, I've decided to try and get MicroEmacs in D added to the du=
b=20
 registry. The last time it compiled was 2 years ago.
=20
 I wound up with at least a dozen references to Phobos names that have=20
 disappeared. No corrective action was indicated, just "undefined symbol".=
I have=20
 to go refigure out what the code was trying to do, and go poking through =
the=20
 Phobos documentation to see what will work today.
=20
 I know there's been a lot of "break my code" advocacy lately, but this co=
de was=20
 only 2 years old.
=20
 I fully understand how unfriendly this is to users and how discouraging i=
t can=20
 be to have their recently working code shattered and scattered. We need t=
o do a=20
 lot better.
like, for example, having some tool that will analyze the old code and autofix it/suggest replacement. oh, wait... such tool was suggested years ago and has no signs of "official blessing" until this year's summer! and now it can't fix two-year-old code.
Nov 28 2014
prev sibling next sibling parent Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 11/28/14, 5:39 PM, ketmar via Digitalmars-d wrote:
 oh, wait... such tool was suggested years ago and has no signs of
 "official blessing" until this year's summer! and now it can't fix
 two-year-old code.
I don't understand this attitude. Don't wait for any sort of gold star rubber stamp ticker tape parade. If you think something is worth doing, do it.
Nov 28 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m5b0p2$1bv4$1 digitalmars.com...

 Just for fun, I've decided to try and get MicroEmacs in D added to the dub 
 registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names that have 
 disappeared. No corrective action was indicated, just "undefined symbol". 
 I have to go refigure out what the code was trying to do, and go poking 
 through the Phobos documentation to see what will work today.

 I know there's been a lot of "break my code" advocacy lately, but this 
 code was only 2 years old.

 I fully understand how unfriendly this is to users and how discouraging it 
 can be to have their recently working code shattered and scattered. We 
 need to do a lot better.
Two years is too old, you skipped all the deprecation stages.
Nov 28 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 3:46 PM, Daniel Murphy wrote:
 Two years is too old, you skipped all the deprecation stages.
My favorite unhelpful message: src/med/spawn.d(62): Error: undefined identifier sleep, did you mean template slurp(Types...)(string filename, in char[] format)? Grepping around revealed that sleep() had migrated to core.sys.posix.unistd
Nov 28 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m5b2dc$1f4j$1 digitalmars.com...

 On 11/28/2014 3:46 PM, Daniel Murphy wrote:
 Two years is too old, you skipped all the deprecation stages.
My favorite unhelpful message: src/med/spawn.d(62): Error: undefined identifier sleep, did you mean template slurp(Types...)(string filename, in char[] format)? Grepping around revealed that sleep() had migrated to core.sys.posix.unistd
I don't know the history on that one, but why did you go straight to the latest compiler? Stepping through (some of) the last two years' releases would quite likely have been the same experience, but with better errors from the deprecation stages.
Nov 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 4:19 PM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:m5b2dc$1f4j$1 digitalmars.com...

 On 11/28/2014 3:46 PM, Daniel Murphy wrote:
 Two years is too old, you skipped all the deprecation stages.
My favorite unhelpful message: src/med/spawn.d(62): Error: undefined identifier sleep, did you mean template slurp(Types...)(string filename, in char[] format)? Grepping around revealed that sleep() had migrated to core.sys.posix.unistd
I don't know the history on that one, but why did you go straight to the latest compiler? Stepping through (some of) the last two years' releases would quite likely have been the same experience, but with better errors from the deprecation stages.
Can't tell users to do that. It's not reasonable.
Nov 28 2014
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m5b5ma$1hfj$1 digitalmars.com... 

 Can't tell users to do that. It's not reasonable.
I don't see why not.
Nov 28 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 29 Nov 2014 12:04:26 +1100
Daniel Murphy via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "Walter Bright"  wrote in message news:m5b5ma$1hfj$1 digitalmars.com...=20
=20
 Can't tell users to do that. It's not reasonable.
=20 I don't see why not.
they will lose all the fun figuring out what that code was meant to do and why they must slurp now.
Nov 28 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Can't tell users to do that. It's not reasonable.
A possible solution: in the standard D distribution you put two or more versions (duplicated) of Phobos (switchable with a compiler switch), so people that don't bother to follow the deprecation cycles can compile even 15 years old D code. Bye, bearophile
Nov 28 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"bearophile"  wrote in message news:rgoeylyaqzlvtgyafsqj forum.dlang.org...

 A possible solution: in the standard D distribution you put two or more 
 versions (duplicated) of Phobos (switchable with a compiler switch), so 
 people that don't bother to follow the deprecation cycles can compile even 
 15 years old D code.
Why not just tell people to use dvm? No reason to make the release zip more gigantic.
Nov 28 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 29, 2014 at 01:11:54AM +0000, bearophile via Digitalmars-d wrote:
 Walter Bright:
 
Can't tell users to do that. It's not reasonable.
A possible solution: in the standard D distribution you put two or more versions (duplicated) of Phobos (switchable with a compiler switch), so people that don't bother to follow the deprecation cycles can compile even 15 years old D code.
[...] The problem with that, is that Phobos often doesn't even compile with the previous release of DMD (or, for that matter, a commit prior to a PR that spans both dmd and Phobos), so it's anyone's guess what an older version of Phobos would do when compiled with a newer compiler. Unless, of course, you maintain the old version enough to keep it compilable with the current compiler. But that's a lot of additional maintenance work. T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Nov 28 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 The problem with that, is that Phobos often doesn't even 
 compile with
 the previous release of DMD (or, for that matter, a commit 
 prior to a PR
 that spans both dmd and Phobos), so it's anyone's guess what an 
 older
 version of Phobos would do when compiled with a newer compiler.

 Unless, of course, you maintain the old version enough to keep 
 it
 compilable with the current compiler. But that's a lot of 
 additional
 maintenance work.
The point of my answer is that I think the problem raised by Walter can't be solved by Phobos/dmd developers. And at the current state of D development trying to solve it will cause more problems (and more wasted efforts) than it can solve. Bye, bearophile
Nov 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 5:29 PM, bearophile wrote:
 The point of my answer is that I think the problem raised by Walter can't be
 solved by Phobos/dmd developers.
Yes, it can be.
Nov 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 5:42 PM, Walter Bright wrote:
 On 11/28/2014 5:29 PM, bearophile wrote:
 The point of my answer is that I think the problem raised by Walter can't be
 solved by Phobos/dmd developers.
Yes, it can be.
1. renaming things to the latest fashion is an illusion of progress, not actual progress, such as fnmatch => globMatch 2. deprecated aliases to the old names can be kept for a long time without causing problems 3. when removed entirely, the documentation for them should be kept along with instructions on corrective action
Nov 28 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Yes, it can be.
A solution is to leave deprected stuff for 2-5 years in Phobos (but in few cases this is not enough, because some names have changed purpose and signature).
 1. renaming things to the latest fashion is an illusion of 
 progress, not actual progress, such as fnmatch => globMatch
You are wrong. Having good function names is extremely important. Renaming badly named things with more clear and more meaningful names reduces pain for both old and new users, reduces coding time, and in some cases even avoids some troubles.
 2. deprecated aliases to the old names can be kept for a long 
 time without causing problems
This is usually true, but not always (see above).
 3. when removed entirely, the documentation for them should be 
 kept along with instructions on corrective action
I agree. Bye, bearophile
Nov 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 5:57 PM, bearophile wrote:
 Walter Bright:
 1. renaming things to the latest fashion is an illusion of progress, not
 actual progress, such as fnmatch => globMatch
You are wrong. Having good function names is extremely important. Renaming badly named things with more clear and more meaningful names reduces pain for both old and new users, reduces coding time, and in some cases even avoids some troubles.
That's largely speculation. I doubt there's an objective case that "globMatch" is superior to "fnmatch". Not only that, "fnmatch" is a familiar and widely used name across diverse languages. Nobody else uses "globMatch". And all these speculative benefits need to be set against the real costs of nothing compiles that is 2+ years old, the annoyed users, the people who got tired of constant code breakage and left, and the lack of a rich set of libraries because of bit rot.
Nov 28 2014
parent reply "Mike" <none none.com> writes:
On Saturday, 29 November 2014 at 02:35:16 UTC, Walter Bright 
wrote:

 And all these speculative benefits need to be set against the 
 real costs of nothing compiles that is 2+ years old,
Ensuring 2 year old code compiles is easily managed by keeping a copy of the tools used to build the code. Upgrade when you have the resources to manage the migration.
 the annoyed users,
Have them see the above comment.
 the people who got tired of constant code breakage and left,
Speculation without measurement. But I'll have you know my usage of D has declined significantly because it is missing features I want/need. It is also for this reason that I have not advocated its usage to my employer. How many users have been lost because they tried it and found it lacking or inefficient, not because of code breakage? I know of 2.
 and the lack of a rich set of libraries because of bit rot.
Yes, D's current business model is not sustainable. It is lacking capable contributors and funds to keep the code maintained. Mike
Nov 28 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 6:59 PM, Mike wrote:
 But I'll have you know my usage of D has
 declined significantly because it is missing features I want/need.  It is also
 for this reason that I have not advocated its usage to my employer.  How many
 users have been lost because they tried it and found it lacking or inefficient,
 not because of code breakage?  I know of 2.
I doubt any of that situation is improved by changing names.
 It is lacking capable contributors and funds to keep the code maintained
Changing names makes the situation worse by consuming scarce resources.
Nov 28 2014
next sibling parent "Mike" <none none.com> writes:
On Saturday, 29 November 2014 at 03:13:37 UTC, Walter Bright 
wrote:

 I doubt any of that situation is improved by changing names.
I was referring to (breaking) changes in general. But with regard to names, yes names are important, which is why they should be chosen carefully up front, and why I intervened on this pull request https://github.com/D-Programming-Language/druntime/pull/999. Mike
Nov 28 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Changing names makes the situation worse by consuming scarce 
 resources.
Changing names make the language/library better, and this can increase the retention rate of new D programmers.
 That's largely speculation. I doubt there's an objective case 
 that "globMatch" is superior to "fnmatch". Not only that, 
 "fnmatch" is a familiar and widely used name across diverse 
 languages. Nobody else uses "globMatch".
Some examples of classes of situations/problems: - In Phobos there are good functions like std.math.feqrel that people aren't using (I have again and again suggested its usage in D.learn) probably because of their bad names. - In Phobos there are names like schwartzSort that while descriptive (if you know what a Schwartz transform is), are awfully hard/bad to type and remember (I suggested a "sortKey" or something equally simple, that is less descriptive, but this is not a big problem because schwartzSort is meant to be used quite frequently in D code). - In Phobos there are also redundant names like std.random.randomShuffle, where in both Python and now C++ "shuffle" suffices. - Regarding the name "familiarity" point you often raise, this has done not so good to D. We have names like "wchar", "dchar" that have no useful meaning, and you need memory to remember their sizes. We have exceptionally badly type names as "byte" and "ubyte" that are bug-prone, etc. Not all future D programmers have 20 years of C/C++ experience of programming. Sometimes a more "algorithmic" naming scheme for types as in Rust is better (it uses a number to denote the length in bytes of number types). Good function names are useful because: - It's simpler to find them when you don't know if Phobos contains something you need; - Once they are found, a well chosen name allows the programmer to understand faster if that's the right function to pick; - Once they are used in the code, a good name makes the code more easy to understand; - Bad names can even cause bugs; - Sometimes when you can't find a good name for a function is a code smell, it means your function is badly designed or should be split in two or more parts. Good naming is essential in programming. Improving some D/Phobos names is very important. I understand the need for API stability, but this doesn't kill the importance of good naming. Adding deprecated to Phobos for years is often acceptable.
 and the lack of a rich set of libraries because of bit rot.
This is not a valid argument. The lack of D libraries has various causes, probably the main one is the lack of D developers and the lack of their interest in keeping the code updated (perhaps because they have left D community?). If you take a look at the Julia language community, the libraries (http://pkg.julialang.org/ ) are being refactored and some names change, but there are lot of people that work furiously improving those libs, so they don't rot, they blossom. Julia is a young language but it already has most numerical libraries for all kinds of scientific work (also because writing average-quality Julia library code requires little time). Bye, bearophile
Nov 29 2014
parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 11:59:36 UTC, bearophile wrote:
<snip>
 and the lack of a rich set of libraries because of bit rot.
This is not a valid argument. The lack of D libraries has various causes, probably the main one is the lack of D developers and the lack of their interest in keeping the code updated (perhaps because they have left D community?). <snip>
ouch.
Nov 29 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 29 Nov 2014 02:59:05 +0000
Mike via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Speculation without measurement.  But I'll have you know my usage=20
 of D has declined significantly because it is missing features I=20
 want/need.  It is also for this reason that I have not advocated=20
 its usage to my employer.
same for me. i was gently pushing our development team towards D (heh, and i'm in position to do that) but now i put a veto on D (yet i'm still using heavily patched D for my own pet projects and have no plans to change that). contrary to what one may think i did that not for code breakage, but due to the developers that continuously rejecting to break our code. we already has the language which is riddled by legacy crap, there is no need to introduce another one. as for now i see that "don't break the code" policy is: a. not working, as the code still breaks. b. turning off developers that want a language without legacy crap. c. not attracting new users to D: new users has no code, so there is nothing to break yet. as for libraries: having native D libraries is good, but not really necessary, 'cause it's not that hard to create imports for C libraries, and we have ALOT of C libraries out here. what is *really* matters is having consistent and solid language to build our code base upon. and a language that progressively dropping legacy leftovers in favor of new and/or better designed features.
Nov 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 7:22 PM, ketmar via Digitalmars-d wrote:
 same for me. i was gently pushing our development team towards D (heh,
 and i'm in position to do that) but now i put a veto on D (yet i'm
 still using heavily patched D for my own pet projects and have no plans
 to change that). contrary to what one may think i did that not for code
 breakage, but due to the developers that continuously rejecting to break
 our code. we already has the language which is riddled by legacy crap,
Please list your top two or three.
Nov 28 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 19:35:29 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/28/2014 7:22 PM, ketmar via Digitalmars-d wrote:
 same for me. i was gently pushing our development team towards D (heh,
 and i'm in position to do that) but now i put a veto on D (yet i'm
 still using heavily patched D for my own pet projects and have no plans
 to change that). contrary to what one may think i did that not for code
 breakage, but due to the developers that continuously rejecting to break
 our code. we already has the language which is riddled by legacy crap,
=20 Please list your top two or three.
top one, after which i vetoed D: issue #13670 as for others -- i was ranting here many times. `foreach (auto n; ...)`? yes, this is *not* a pure cosmetic issue: i'm still not able to logically explain why `foreach (n; ...)` doesn't reuse the existing variable but declaring new local. `foreach (; ...)`? `new char[256]`, but not `new char[256][256]` (yes, i know; just make `new char[256]` invalid too and that's all). ' ' in some attribute but not in another. warnings about prefix function attributes. and so on. sure, those aren't very big things per se, but they making language inconsistent. and if i have to teach people inconsistent language, i'll choose C++: it's very bad, i don't even want to thing about it, especially after what D promises and gives to me, but... but C++ at least has alot of reusable code. and D is in position where it can try to not accumulate legacy crap -- that's what i expecting from the modern language. it's ok for us to fix the broken code if that breakage makes language better. ah, i wrote that many times already. i'm still hoping that something will change (that's why i'm still writing this shit), but i backed to the position "nope, we'll not go D yet". for now i'll wait for either D that rapidly changes removing crap and fixing legacy things, or for D that is 20+ years old and has alot of code written in it.
Nov 28 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Saturday, 29 November 2014 at 02:59:07 UTC, Mike wrote:

 the people who got tired of constant code breakage and left,
Speculation without measurement. But I'll have you know my usage of D has declined significantly because it is missing features I want/need. It is also for this reason that I have not advocated its usage to my employer. How many users have been lost because they tried it and found it lacking or inefficient, not because of code breakage? I know of 2.
Walter, I want you to know, that I love D. It is an awesome language with enormous potential. But it needs to break with a few of the decisions from the past (very few, but significant), and follow through on a few things (like the scope ref proposals). IMO, it's *almost* there. If I(we) can ever get it there, it will likely be the last language I ever use. Mike
Nov 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 7:42 PM, Mike wrote:
 Walter, I want you to know, that I love D.  It is an awesome language with
 enormous potential.  But it needs to break with a few of the decisions from the
 past (very few, but significant), and follow through on a few things (like the
 scope ref proposals).  IMO, it's *almost* there.  If I(we) can ever get it
 there, it will likely be the last language I ever use.
Actually, we've (myself and 3 others) been hard at work preparing a scope ref proposal. It isn't quite ready to present yet. I agree it is of major importance. It will also slightly break some code, but we have a plan for dealing with that to make it as painless as possible. I believe that scope ref is a big enough win to justify it. What I don't agree with are changing names of things that just cause needless frustration, and are, as I tactlessly put it, an illusion of progress.
Nov 28 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 20:03:44 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 What I don't agree with are changing names of things that just cause need=
less=20
 frustration, and are, as I tactlessly put it, an illusion of progress.
it seems to me that you are very pragmatic person (in a good sense) and with all your expiriense in software development you are underestimating the influense of "cosmetic changes", such as better naming. you are used to "fnmatch" and you don't care if it stays as is or not, so why bother to change? but for heterogeneous teams where we have both expirienced developers and juniors naming matters. it's much easier to read and to remember what 'globMatch' do than what 'fnmatch' do. i, for myself, knowing that function for years still confused a little trying to understand what it has with "function matching". and only after some pause i remembers that it's "filename matching". the same for the things i'm constantly ranting about: "just remember it" for such things is not good. people keep asking me "why?" and all i can answer is "this is the way of the things. just remember it and don't question."
Nov 28 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
dammit, my English sux even worse when i trying to say something
important...
Nov 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 8:25 PM, ketmar via Digitalmars-d wrote:
 dammit, my English sux even worse when i trying to say something
 important...
No prob, I understand you just fine!
Nov 28 2014
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Saturday, 29 November 2014 at 04:03:47 UTC, Walter Bright 
wrote:
 Actually, we've (myself and 3 others) been hard at work 
 preparing a scope ref proposal. It isn't quite ready to present 
 yet. I agree it is of major importance. It will also slightly 
 break some code, but we have a plan for dealing with that to 
 make it as painless as possible. I believe that scope ref is a 
 big enough win to justify it.
That's a very good news. --- Paolo
Nov 29 2014
prev sibling parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 02:59:07 UTC, Mike wrote:
<snip>
 and the lack of a rich set of libraries because of bit rot.
Yes, D's current business model is not sustainable. It is lacking capable contributors and funds to keep the code maintained. Mike
Agree.
Nov 29 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 29, 2014 at 10:46:14AM +1100, Daniel Murphy via Digitalmars-d wrote:
 "Walter Bright"  wrote in message news:m5b0p2$1bv4$1 digitalmars.com...
 
Just for fun, I've decided to try and get MicroEmacs in D added to
the dub registry. The last time it compiled was 2 years ago.

I wound up with at least a dozen references to Phobos names that have
disappeared. No corrective action was indicated, just "undefined
symbol".  I have to go refigure out what the code was trying to do,
and go poking through the Phobos documentation to see what will work
today.

I know there's been a lot of "break my code" advocacy lately, but
this code was only 2 years old.

I fully understand how unfriendly this is to users and how
discouraging it can be to have their recently working code shattered
and scattered. We need to do a lot better.
Two years is too old, you skipped all the deprecation stages.
From an end user's POV, though, two years does seem like a short time. I
mean, I have C/C++ projects dating from 20 years ago, and you wouldn't believe it, but almost all of them compile with no change on a modern compiler. Granted, the comparison isn't altogether fair, since D is changing a lot faster than C/C++, but still, 2 years is quite short from that POV. Not everybody is constantly trying to compile code with git HEAD and fixing compiling errors on every personal pet project they have, that, on the off-chance, might stop compiling after 2 years. Perhaps it's time to reconsider the length of the deprecation cycle, from an end user's POV, rather than from the POV of the D devs who can't wait to junk the old stuff and move on to the new. Alternatively, we should have a "compatibility mode" for the compiler / Phobos, where certain parts of the code are version'd out as they get deprecated, but you can get them back by using an appropriate version declaration: // Some phobos module version(PhobosCompat_2066) { // Old version - compile with version=PhobosCompat_2066 // to get this symbol back auto oldSymbol(...) { ... } } else { // New version deprecated("Please use newSymbol instead.") auto oldSymbol(...) { ... } } This works reasonably well for Phobos, but I don't know how to do this in the compiler without ending up with an ugly plate of unmaintainable spaghetti. T -- In theory, there is no difference between theory and practice.
Nov 28 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.2437.1417219611.9932.digitalmars-d puremagic.com...

 From an end user's POV, though, two years does seem like a short time. I
 mean, I have C/C++ projects dating from 20 years ago, and you wouldn't
 believe it, but almost all of them compile with no change on a modern
 compiler. Granted, the comparison isn't altogether fair, since D is
 changing a lot faster than C/C++, but still, 2 years is quite short from
 that POV. Not everybody is constantly trying to compile code with git
 HEAD and fixing compiling errors on every personal pet project they
 have, that, on the off-chance, might stop compiling after 2 years.
I don't think it's reasonable to support those expectations in phobos. You don't need to constantly compile with git HEAD, just upgrade in smaller steps than 2 years.
 Perhaps it's time to reconsider the length of the deprecation cycle,
 from an end user's POV, rather than from the POV of the D devs who can't
 wait to junk the old stuff and move on to the new.
Maintaining only junk has a cost, and development is slow enough as it is.
 Alternatively, we should have a "compatibility mode" for the compiler /
 Phobos, where certain parts of the code are version'd out as they get
 deprecated, but you can get them back by using an appropriate version
 declaration:

 This works reasonably well for Phobos, but I don't know how to do this
 in the compiler without ending up with an ugly plate of unmaintainable
 spaghetti.
I don't think it works well for either, but it really doesn't work for the compiler. Everything depends on everything else and often motivation for actually getting around to removing features comes from how much of a pain they are to maintain.
Nov 28 2014
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, November 29, 2014 10:46:14 Daniel Murphy via Digitalmars-d wrote:
 Two years is too old, you skipped all the deprecation stages.
That's pretty much the long and short of it. The deprecation cycle for stuff in druntime/Phobos is currently about two years long (one year as deprecated and documented, one year as deprecated and undocumented). So, anything that had been in the deprecation cycle when Walter last touched that code would be long out of it by now, and depending on when the releases really fell vs how close to two years it's really been, it wouldn't be that hard for some stuff to have started and completed the deprecation cycle since the last time he updated that code. We haven't even been trying to make it so that code can be unmaintained for two years and then still build with no changes. It's pretty much been the expectation that anything untouched for that long is essentially dead. We don't deprecate anywhere near as much stuff as we used to or do it anywhere near as frequently, but two years is long enough that you're going to skip the entire deprecation cycle for stuff. We can certainly look at increasing the length of time for the deprecation process, but that creates more cruft in the library, increases the risk of symbol conflicts and makes for more code to maintain - code that shouldn't even be used anymore. The primary solution has been simply to raise the bar for what changes we'll accept that will result in deprecations. But they still happen sometimes if the change is deemed worthwhile enough (in particular, it sounds like Walter's big problem is that std.path was redone a while back, which was definitely more than simply renaming stuff). And the only way to outright prevent code breaking due to changes like this, we'd have to keep deprecated stuff around indefinitely, which is a maintenance problem. I'm not completely against increasing the length of the deprecation cycle in order to reduce the risk of code breaking without notice when it's not actively maintained (e.g. from two years to three), but I also don't think that it's completely reasonable to expect that code which is untouched for two years will work with the latest compiler and library. Not even the language itself is that stable, and it's a _lot_ more stable than it used to be. I completely agree that we should be trying to reduce code breakage even over longer periods of time (and I think that we definitely _have_ reduced it, even if it's not by enough to allow Walter to compile his two year old microemacs code without using any compilers in between), but I also think that the expectation that old code should compile several years later with no changes and without using any compilers in between is higher than reasonable. I'm not sure that that even works with C++ compilers, much as it should - especially when you go from C++98 to C++11 or C++14, and since D is continually in flux (even if it's a lot less flux than it used to be), doing something like going from 2.058 to 2.066 is a lot like going from C++98 to C++11. To really have full stability, we'd pretty much have to freeze everything and change nothing beyond bug fixes, and we're definitely not doing that. Heck, simply introducing a new function to Phobos can break existing code, because it can create a symbol conflict. It's an easy fix, but stuff like that makes it nigh on impossible to guarantee that we won't break two-year old code. - Jonathan M Davis
Nov 30 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
You probably have realized that the obvious solution to breakage 
is:

1. To have two branches: stable and experimental

2. Backport serious bugfixes to stable, but not "bug is a 
feature" bugs.

3. Provide an upgrade tool when a new stable branch is created 
(meaning: a new stable branch is not created until the 
source-code upgrade tool is ready)

4. Create a planned release scheduled for stable branch (say 
18-24 months)
Nov 30 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Nov 30, 2014 at 12:55:34PM +0000, via Digitalmars-d wrote:
 You probably have realized that the obvious solution to breakage is:
 
 1. To have two branches: stable and experimental
 
 2. Backport serious bugfixes to stable, but not "bug is a feature"
 bugs.
 
 3. Provide an upgrade tool when a new stable branch is created
 (meaning: a new stable branch is not created until the source-code
 upgrade tool is ready)
 
 4. Create a planned release scheduled for stable branch (say 18-24
 months)
This wouldn't help Walter's original problem. He was taking code written from >=2 years ago and compiling it with the latest compiler. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
Nov 30 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 30 November 2014 at 15:32:31 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 This wouldn't help Walter's original problem. He was taking 
 code written
 from >=2 years ago and compiling it with the latest compiler.
I assumed he meant to make a forward looking statement, i.e. how to deal with this from now on. In two years Walter would run the upgradetool spanning 1-2 releases, and get the automatic fixes and the warnings where manual intervention is needed.
Nov 30 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Nov 30, 2014 at 03:03:23AM -0800, Jonathan M Davis via Digitalmars-d
wrote:
[...]
 be. I completely agree that we should be trying to reduce code
 breakage even over longer periods of time (and I think that we
 definitely _have_ reduced it, even if it's not by enough to allow
 Walter to compile his two year old microemacs code without using any
 compilers in between), but I also think that the expectation that old
 code should compile several years later with no changes and without
 using any compilers in between is higher than reasonable. I'm not sure
 that that even works with C++ compilers, much as it should -
 especially when you go from C++98 to C++11 or C++14, and since D is
 continually in flux (even if it's a lot less flux than it used to be),
 doing something like going from 2.058 to 2.066 is a lot like going
 from C++98 to C++11.
FWIW, I have C++ code dating from 10 years ago that still compiles with C++11. Granted, I needed to fix a thing or two here and there, but they were pretty straightforward (compiler warnings / errors told you exactly why the code doesn't work anymore). But then again, it's not like C++11 replaced an entire standard library module in the process -- they did introduce new and better modules but old ones were kept around.
 To really have full stability, we'd pretty much have to freeze
 everything and change nothing beyond bug fixes, and we're definitely
 not doing that. Heck, simply introducing a new function to Phobos can
 break existing code, because it can create a symbol conflict.
Speaking of which, this problem is made a lot worse than it could be, because currently private symbols in imported modules are included in the overload set, so introducing a *private* symbol can break unrelated user code downstream. Ugh.
 It's an easy fix, but stuff like that makes it nigh on impossible to
 guarantee that we won't break two-year old code.
[...] I think the complaint was not so much the fact that the code broke, but the fact that it broke *without any clue as to how to fix it*. Now, if we had something like disable with an optional message, we could do something like: disabled("Please use globMatch instead") auto fnmatch(...); At least in theory, this would fix the problem. Of course, in practice, things rarely work out so nicely except in retrospect. :-P T -- MAS = Mana Ada Sistem?
Nov 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2014 7:28 AM, H. S. Teoh via Digitalmars-d wrote:
 I think the complaint was not so much the fact that the code broke, but
 the fact that it broke *without any clue as to how to fix it*.
Yup. Consider the fnmatch => globMatch change. Just edit the name, right? Easy-peesy, right? But: 1. the guy given the job of updating the software is not the guy who wrote it - he doesn't know what the code is intending to do 2. He gets "fnmatch is undefined" 3. there's no documentation for fnmatch anymore. He has no idea what fnmatch is supposed to do. Now he's got to embark on some sort of forensic search through old versions of the compiler, and not having much clue which ones to look at 4. he figures out what it does, then starts poking through the Phobos documentation looking for something that might work 5. he finds globMatch, it looks like it'll work 6. hopefully he's got a good test suite to verify that it is actually the correct replacement A simple name change has turned into a fair amount of work.
 Now, if we had something like  disable with an optional message, we could do
 something like:

 	 disabled("Please use globMatch instead") auto fnmatch(...);

 At least in theory, this would fix the problem. Of course, in practice,
 things rarely work out so nicely except in retrospect. :-P
Keeping around a deprecated alias translating the old symbol to the new one is a good approach. For a more detailed message, instead of the disabled enhancement, a simpler way is: void fnmatch()(...) { static assert(0, "use globMatch instead of fnmatch"); }
Nov 30 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Nov 30, 2014 at 03:03:37PM -0800, Walter Bright via Digitalmars-d wrote:
[...]
 Keeping around a deprecated alias translating the old symbol to the
 new one is a good approach. For a more detailed message, instead of
 the  disabled enhancement, a simpler way is:
 
   void fnmatch()(...) {
     static assert(0, "use globMatch instead of fnmatch");
   }
[...] That's a good idea. Keep in mind, though, that in this particular case, std.path was essentially replaced wholesale, so does that mean that every time we replaced a module, we have to keep the entire old set of symbols around basically forever? T -- It said to install Windows 2000 or better, so I installed Linux instead.
Nov 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2014 6:01 PM, H. S. Teoh via Digitalmars-d wrote:
 On Sun, Nov 30, 2014 at 03:03:37PM -0800, Walter Bright via Digitalmars-d
wrote:
 [...]
 Keeping around a deprecated alias translating the old symbol to the
 new one is a good approach. For a more detailed message, instead of
 the  disabled enhancement, a simpler way is:

    void fnmatch()(...) {
      static assert(0, "use globMatch instead of fnmatch");
    }
[...] That's a good idea.
Thanks! I like pressing existing features into use over inventing new ones :-)
 Keep in mind, though, that in this particular case, std.path was
 essentially replaced wholesale, so does that mean that every time we
 replaced a module, we have to keep the entire old set of symbols around
 basically forever?
Why not? D's module system is very good at avoiding name collisions, and dealing with them when they do arise. Not only that, it's probably a good idea for new modules in Phobos to avoid collisions with old names, even when the old names are removed, so that people are not confused when they try to recompile old projects.
Nov 30 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Thanks! I like pressing existing features into use over 
 inventing new ones :-)
The existing feature to be used is deprecated, it's more self-documenting and it was designed for that purpose. Using that special assert is just a workaround. No one was suggesting to invent new feature, but to add a string argument to the right feature to use.
 Why not?
Because it's ugly, and ugly things usually later manage to find ways to give you troubles.
 it's probably a good idea for new modules in Phobos to avoid 
 collisions with old names, even when the old names are removed, 
 so that people are not confused when they try to recompile old 
 projects.
In few (not common) cases it's better to re-use an old name for different better purposes. Bye, bearophile
Dec 01 2014
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, December 01, 2014 09:57:33 bearophile via Digitalmars-d wrote:
 Walter Bright:

 Thanks! I like pressing existing features into use over
 inventing new ones :-)
The existing feature to be used is deprecated, it's more self-documenting and it was designed for that purpose. Using that special assert is just a workaround. No one was suggesting to invent new feature, but to add a string argument to the right feature to use.
The primary difference is that deprecated symbols are still usable, whereas a disabled wouldn't be - nor would a function with static assert(0) in it be usable. And if a something in Phobos is usuable, then we need to maintain it, and that's a problem if we're trying to get rid of it. A function that results in a static assertion when used is still a problem, because it does leave cruft in the library, and it creates symbol conflicts with any symbols which happen to use the same name, but it's still better than leaving something as deprecated permanently. - Jonathan M Davis
Dec 01 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 but it's still better than leaving something as deprecated 
 permanently.
Right, sorry, I meant disabled. But I don't like to keep those things disabled permanently, they eventually should be removed. Bye, bearophile
Dec 01 2014
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, December 01, 2014 11:21:23 bearophile via Digitalmars-d wrote:
 Jonathan M Davis:

 but it's still better than leaving something as deprecated
 permanently.
Right, sorry, I meant disabled. But I don't like to keep those things disabled permanently, they eventually should be removed.
I agree. I do think that we should strive for stability and backwards compatibility, but if we're getting rid of something, then I think that we should actually get rid of it at some point. That's part of why we have the deprecation process that we have. - Jonathan M Davis
Dec 01 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Monday, 1 December 2014 at 11:52:04 UTC, Jonathan M Davis via
Digitalmars-d wrote:
 On Monday, December 01, 2014 11:21:23 bearophile via
 Digitalmars-d wrote:
 Right, sorry, I meant disabled.  But I don't like to keep those
 things disabled permanently, they eventually should be removed.
I agree. I do think that we should strive for stability and backwards compatibility, but if we're getting rid of something, then I think that we should actually get rid of it at some point. That's part of why we have the deprecation process that we have.
Thinking along these lines, would it be possible to have something like a deprecation module (core.deprecations?) that you can import (temporarily) for updating old code? At the very least, it seems it would be possible to alias and warn with pragma for some changed names, and error at compile time with an informative message otherwise. Maybe feed it a version the project last built with to narrow what changes might be. In a more magical future, the compiler might automatically import it with a switch and obviate the need for manually changing files, or tools could be built to use it finding trouble spots and automated updates (more for dfix, I suppose). -Wyatt
Dec 01 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2014 8:17 AM, Wyatt wrote:
 Thinking along these lines, would it be possible to have something like a
 deprecation module (core.deprecations?) that you can import (temporarily) for
 updating old code? At the very least, it seems it would be possible to alias
and
 warn with pragma for some changed names, and error at compile time with an
 informative message otherwise.
Not exactly what you suggest, but: http://code.dlang.org/packages/undead https://github.com/DigitalMars/undeaD
Dec 01 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Dec 01, 2014 at 03:51:48AM -0800, Jonathan M Davis via Digitalmars-d
wrote:
 On Monday, December 01, 2014 11:21:23 bearophile via Digitalmars-d wrote:
 Jonathan M Davis:

 but it's still better than leaving something as deprecated
 permanently.
Right, sorry, I meant disabled. But I don't like to keep those things disabled permanently, they eventually should be removed.
I agree. I do think that we should strive for stability and backwards compatibility, but if we're getting rid of something, then I think that we should actually get rid of it at some point. That's part of why we have the deprecation process that we have.
[...] I agree that if we're gonna remove something, we should actually *remove* it, not just leave an empty husk behind forever cluttering the code. That's why I suggested lengthening the deprecation cycle. But OTOH, how long can you drag out the deprecation process before it essentially becomes needless cruft that we're forced to carry around "almost forever"? T -- The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Dec 01 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2014 1:57 AM, bearophile wrote:
 Walter Bright:

 Thanks! I like pressing existing features into use over inventing new ones :-)
The existing feature to be used is deprecated, it's more self-documenting and it was designed for that purpose. Using that special assert is just a workaround. No one was suggesting to invent new feature, but to add a string argument to the right feature to use.
That is inventing a new feature.
Dec 01 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 1 December 2014 at 02:44:24 UTC, Walter Bright wrote:
 D's module system is very good at avoiding name collisions, and 
 dealing with them when they do arise.
Really laughed here. dstep got broken when going from 2.065 to 2.066 exactly because new symbol was added to object.d and it clashed with one defined in application. Very good in avoiding name collisions, right.
Dec 04 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 30 Nov 2014 18:01:34 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 On Sun, Nov 30, 2014 at 03:03:37PM -0800, Walter Bright via Digitalmars-d=
wrote:
 [...]
 Keeping around a deprecated alias translating the old symbol to the
 new one is a good approach. For a more detailed message, instead of
 the  disabled enhancement, a simpler way is:
=20
   void fnmatch()(...) {
     static assert(0, "use globMatch instead of fnmatch");
   }
[...] =20 That's a good idea. =20 Keep in mind, though, that in this particular case, std.path was essentially replaced wholesale, so does that mean that every time we replaced a module, we have to keep the entire old set of symbols around basically forever?
this whole thing is a work for dfix, i believe. there's no need to keep alot of junk in libraries where dfix can do much better work.
Nov 30 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-12-01 00:03, Walter Bright wrote:

 3. there's no documentation for fnmatch anymore. He has no idea what
 fnmatch is supposed to do. Now he's got to embark on some sort of
 forensic search through old versions of the compiler, and not having
 much clue which ones to look at
$ git log -S 'fnmatch' Is a good command for that. -- /Jacob Carlborg
Dec 01 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2014 12:22 AM, Jacob Carlborg wrote:
 On 2014-12-01 00:03, Walter Bright wrote:

 3. there's no documentation for fnmatch anymore. He has no idea what
 fnmatch is supposed to do. Now he's got to embark on some sort of
 forensic search through old versions of the compiler, and not having
 much clue which ones to look at
$ git log -S 'fnmatch' Is a good command for that.
I didn't know that. Thanks for the tip!
Dec 01 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-12-01 00:03, Walter Bright wrote:

 Keeping around a deprecated alias translating the old symbol to the new
 one is a good approach. For a more detailed message, instead of the
  disabled enhancement, a simpler way is:

    void fnmatch()(...) {
      static assert(0, "use globMatch instead of fnmatch");
    }
That doesn't work for virtual methods. Although I think they are quite few in Phobos. -- /Jacob Carlborg
Dec 01 2014
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/30/14 6:03 PM, Walter Bright wrote:
 On 11/30/2014 7:28 AM, H. S. Teoh via Digitalmars-d wrote:
 I think the complaint was not so much the fact that the code broke, but
 the fact that it broke *without any clue as to how to fix it*.
Yup. Consider the fnmatch => globMatch change. Just edit the name, right? Easy-peesy, right? But: 1. the guy given the job of updating the software is not the guy who wrote it - he doesn't know what the code is intending to do 2. He gets "fnmatch is undefined" 3. there's no documentation for fnmatch anymore. He has no idea what fnmatch is supposed to do. Now he's got to embark on some sort of forensic search through old versions of the compiler, and not having much clue which ones to look at 4. he figures out what it does, then starts poking through the Phobos documentation looking for something that might work 5. he finds globMatch, it looks like it'll work 6. hopefully he's got a good test suite to verify that it is actually the correct replacement A simple name change has turned into a fair amount of work.
 Now, if we had something like  disable with an optional message, we
 could do
 something like:

      disabled("Please use globMatch instead") auto fnmatch(...);

 At least in theory, this would fix the problem. Of course, in practice,
 things rarely work out so nicely except in retrospect. :-P
Keeping around a deprecated alias translating the old symbol to the new one is a good approach. For a more detailed message, instead of the disabled enhancement, a simpler way is: void fnmatch()(...) { static assert(0, "use globMatch instead of fnmatch"); }
I propose a new feature: /++ globMatch does blah blah blah Oldname: fnmatch +/ dmd -checkoldnames myoldproject.d Error: fnmatch not defined. Note: globMatch says that it used to be called fnmatch. It isn't often we change names of things just to change the name. And if we do, it's because the name is so bad. I agree with bearophile, the name of things is *very* important, and shouldn't be prevented from changing. Note, we could add ddoc comments for moving symbols to different modules too. /++ Movedname: sleep => core.sys.posix.unistd.sleep +/ I can't help but think that some sort of version(CompiledWith2065) statements wouldn't help, but they would be really messy. I like the idea of including old names in the docs, because that's really where it should be, and it adds a note in the documentation. It can also be amended retroactively when people find those cases, and it's documentation. Documentation changes don't require any unit tests or special explanations, they are just documents. Making it usable by automated tools can only help. -Steve
Dec 01 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 We need to do a lot better.
I agree. D has to come back to the living. It looks like D is hibernating. Bye, bearophile
Nov 28 2014
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Friday, 28 November 2014 at 23:50:52 UTC, bearophile wrote:
 Walter Bright:

 We need to do a lot better.
I agree. D has to come back to the living. It looks like D is hibernating. Bye, bearophile
As much as I like D, hibernating is a very kind way to put it. D feels very ugly/kludgy with all the properties and vomit everywhere and that's something that will never get fixed without serious backwards compatibility breakage. IMO rust got it right with immutable by default, but hindsight is grand(To be fair, rust lifetime management is really ugly too)
Nov 28 2014
parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 07:17:48 UTC, weaselcat wrote:
<snip> IMO rust got it right
 with immutable by default, but hindsight is grand(To be fair, 
 rust lifetime management is really ugly too)
Immutable as default sounds good (in core)
Nov 29 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 3:50 PM, bearophile wrote:
 I agree. D has to come back to the living. It looks like D is hibernating.
I have no idea what you're talking about.
Nov 29 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 On 11/28/2014 3:50 PM, bearophile wrote:
 I agree. D has to come back to the living. It looks like D is 
 hibernating.
I have no idea what you're talking about.
In the last several years the development of D/Phobos didn't keep a constant speed (and this is normal), I have seen sprints, slowdowns, etc. In the latest months I'm seeing a reduction of activity both on the language side, on the fixing and merging of important Phobos patches, and even regarding the number of interesting discussions in the main D newsgroup. Some of this "hibernation" could be caused by the latest "revolution" threads by Andrei. But probably there are also other causes. Or perhaps I'm just mis-measuring the kind of D activity, and everything is going on as well as usual :-) Bye, bearophile
Nov 29 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 29 November 2014 at 11:37:52 UTC, bearophile wrote:
 Some of this "hibernation" could be caused by the latest 
 "revolution" threads by Andrei. But probably there are also 
 other causes.

 Or perhaps I'm just mis-measuring the kind of D activity, and 
 everything is going on as well as usual :-)
I got very happy when Walter announced " nogc" and his intent to create a "better C" switch on the compiler. I felt this was a nice change of direction, but I also feel that this direction has stagnated and taken a turn for the worse with the ref-counting focus… Phobos is too much of a scripting-language library to me, too much like Tango, and hacking in ref counting makes it even more so. To me, a "better C" would have a minimal runtime, a tight minimalistic standard library and very simple builtin ownership semantics (uniqe_ptr). Then a set of supporting libraries that are hardware-optimized (with varying degree of portability). However, I think those that are interested in D as a tight system level language have to spec out "better C" themselves as a formal language spec sketch. I'd be happy to contribute to that, maybe we could start a wiki-page. Since a "better C" would break existing code, it would allow a more "idealistic" language design discussion. I think that could cut down on the noise. I think an experiment would be worth it.
Nov 29 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ola Fosheim Grøstad:

 Phobos is too much of a scripting-language library to me, too 
 much like Tango, and hacking in ref counting makes it even more 
 so.
Those "scripting" needs are real, and rather common. Those high level things are worth having in Phobos. On the other hand it's also reasonable to desire something more fit for a lower level kind of coding. One solution is to split Phobos in two groups of functions, for the two usages (and to forbid the lower level functions to call the high level ones), and ship the compiler with both parts. There is already "Phobos core", but I don't know if its meaning is the same as you desire (probably not).
 To me, a "better C" would have a minimal runtime, a tight 
 minimalistic standard library and very simple builtin ownership 
 semantics (uniqe_ptr). Then a set of supporting libraries that 
 are hardware-optimized (with varying degree of portability).
Clearly D is not a "better C", it's a "better C++/Java". You can use D as a "better C" but this needs some adaptation, both for you and the libraries.
 However, I think those that are interested in D as a tight 
 system level language have to spec out "better C" themselves as 
 a formal language spec sketch. I'd be happy to contribute to 
 that, maybe we could start a wiki-page. Since a "better C" 
 would break existing code, it would allow a more "idealistic" 
 language design discussion. I think that could cut down on the 
 noise.

 I think an experiment would be worth it.
As usual in open source a good way to do things is to start them yourself and look at how many persons are interested. But from what I'm seeing Rust is putting itself at a level lower than D, with all its care for its "no runtime", it even has annotations and standard library sections for this kind of usage. Bye, bearophile
Nov 29 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 29 November 2014 at 12:08:08 UTC, bearophile wrote:
 Those "scripting" needs are real, and rather common. Those high 
 level things are worth having in Phobos. On the other hand it's 
 also reasonable to desire something more fit for a lower level 
 kind of coding. One solution is to split Phobos in two groups 
 of functions, for the two usages (and to forbid the lower level 
 functions to call the high level ones), and ship the compiler
"scripting" needs depend on the application area, the core standard library should only contain the most commonly needed functionality that will work for all applications. With a big standard library you get this effect: big monolithic standard library -> other libraries build on it -> many libraries are unsuitable for more restricted applications big monolithic standard library -> hard to keep bug free, performant and makes language changes more difficult What you want is this: tight standard library -> other libraries build on it if they can-> more libraries are suitable for all applications tight standard library -> high degree of stability -> less breakage of other libraries tight standard library -> better results for library-aware optimizations Then you can have a second optional profile for more unstable scripty libraries, a standardized "extras".
 with both parts. There is already "Phobos core", but I don't 
 know if its meaning is the same as you desire (probably not).
No, I think a lot of what is in "core" is really things that should either be in the language or as compiler intrinsics that the optimizer can deal with.
 Clearly D is not a "better C", it's a "better C++/Java". You 
 can use D as a "better C" but this needs some adaptation, both 
 for you and the libraries.
Yes, but if you can look at D1 as being between C/C++ with GC. I think that is a comfortable spot, if you remove the stuff that the implies a mandatory GC. I think D2 is better off by focusing on stability, evolving in radical changes is difficult. So the more rational approach is to look at the possibility for a D3 on paper and spec a core language that is GC-free, but which can have a more "scripty" GCish profile built on top of it. When you have that, it become easier to improve D2 too, because you have something (hopefully) coherent to compare D2 against. If you have something (on paper) that as a whole is a lot more consistent than D2 then maybe it will be more convincing than arguing tiny feature improvements in isolation. Because those tiny improvements might not seem to be worth it alone. But a new holistic design that captures a lot of the current practice in a cleaner way is going to be much harder to pass on.
 As usual in open source a good way to do things is to start 
 them yourself and look at how many persons are interested.
Sure, I have for many years sketched out various on-paper-designs for languages, I am sure many others do to. The problem is finding common ground since people have different programming styles, experiences and different level of theoretical understanding. By starting with D1/D2 as a common ground it might be possible to create a paper spec for a tiny-D3 that could both support a reduced system language profile and later support an extended "scripty" profile.
 But from what I'm seeing Rust is putting itself at a level 
 lower than D, with all its care for its "no runtime", it even 
 has annotations and standard library sections for this kind of 
 usage.
The problem (and advantage) with opinionated languages like Rust and Go is that they restrict their application area. I also feel that the GC'ed D is constraining, but less so than Rust and Go. Ada is also a well rounded language, but it is a bit verbose for smaller projects. So I think there is an open spot for a streamlined D'ish language between C/C++ with some of the qualities of Ada/Go/Rust/etc. I don't think D is easy to streamline by evolution alone. If you want to arrive at something coherent you need to create abstractions over existing idioms in D programming (interpret current practice through theory) and not create abstractions over the language and libraries (the actual code).
Nov 29 2014
parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 14:40:47 UTC, Ola Fosheim 
Grøstad wrote:
<snip>
 With a big standard library you get this effect:

 big monolithic standard library -> other libraries build on it 
 -> many libraries are unsuitable for more restricted 
 applications

 big monolithic standard library -> hard to keep bug free, 
 performant and makes language changes more difficult

 What you want is this:

 tight standard library -> other libraries build on it if they 
 can-> more libraries are suitable for all applications

 tight standard library -> high degree of stability -> less 
 breakage of other libraries

 tight standard library -> better results for library-aware 
 optimizations

 <snip>
+1
 Clearly D is not a "better C", it's a "better C++/Java". You 
 can use D as a "better C" but this needs some adaptation, both 
 for you and the libraries.
<snip>
It is a bit of false advertising to on website promote D as better C, when the efforts are that it is a better C++/Java/CLR. (and I think you can do both w/ a split).
Nov 29 2014
prev sibling parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 11:56:31 UTC, Ola Fosheim
Grøstad wrote:
<snip>
 I got very happy when Walter announced " nogc" and his intent 
 to create a "better C" switch on the compiler.

 I felt this was a nice change of direction, but I also feel 
 that this direction has stagnated and taken a turn for the 
 worse with the ref-counting focus… Phobos is too much of a 
 scripting-language library to me, too much like Tango, and 
 hacking in ref counting makes it even more so.

 To me, a "better C" would have a minimal runtime, a tight 
 minimalistic standard library and very simple builtin ownership 
 semantics (uniqe_ptr). Then a set of supporting libraries that 
 are hardware-optimized (with varying degree of portability).
<snip> agree.
Nov 29 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 29, 2014 at 11:37:51AM +0000, bearophile via Digitalmars-d wrote:
 Walter Bright:
 
On 11/28/2014 3:50 PM, bearophile wrote:
I agree. D has to come back to the living. It looks like D is
hibernating.
I have no idea what you're talking about.
In the last several years the development of D/Phobos didn't keep a constant speed (and this is normal), I have seen sprints, slowdowns, etc. In the latest months I'm seeing a reduction of activity both on the language side, on the fixing and merging of important Phobos patches, and even regarding the number of interesting discussions in the main D newsgroup.
Huh??! I *really* don't know what you're talking about, because in the last few months, I've seen a dramatic *increase* in Phobos activity. We've seen the PR queue shrink from 95+ to the mid 30's within 1-2 months, and recently there's been a whole bunch of PR's that got merged (Ilya's import cleanups, for example, span almost all of Phobos and got merged within days of each submission), plus a bunch of new features coming in so fast that the queue is growing again since the committers haven't been able to keep up with the pace. There has been Igor's extremely critical work on finally prepping the AA implementation to be implementable in the library, which is almost reaching its final stages now. If anything, I'd say D is waking up, rather than hibernating! Judging language progress by forum discussions is unreliable... if anything, in *my* experience there's a rather low S/N ratio on the forum in terms of what actually gets done. Perhaps more people have clued in to the fact that asking for things on the forums doesn't work so well, and have started to submit PR's instead? ;-) [...]
 Or perhaps I'm just mis-measuring the kind of D activity, and
 everything is going on as well as usual :-)
[...] How are you measuring D activity? Forum activity is unreliable. Did you look at github commit statistics? T -- Too many people have open minds but closed eyes.
Nov 29 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 Huh??! I *really* don't know what you're talking about, because 
 in the
 last few months, I've seen a dramatic *increase* in Phobos 
 activity.
OK, if I was mistaken then I am happy ::) Sometimes it's good to be wrong. Bye, bearophile
Nov 29 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/29/14 8:09 AM, bearophile wrote:
 H. S. Teoh:

 Huh??! I *really* don't know what you're talking about, because in the
 last few months, I've seen a dramatic *increase* in Phobos activity.
OK, if I was mistaken then I am happy ::) Sometimes it's good to be wrong.
Might be because my participation has been scarce lately (busy with work and family). I'll also be out at the YOW conference (http://yowconference.com.au), talking about D. One interesting tidbit is that downloads have been rising sharply through mid-November, to have a bit of a pullback recently: http://erdani.com/d/downloads.daily.png I wonder if there's some way to filter out robots, build machines etc. Ideas? Andrei
Dec 01 2014
next sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Tuesday, 2 December 2014 at 00:13:03 UTC, Andrei Alexandrescu
wrote:
 I wonder if there's some way to filter out robots, build 
 machines etc. Ideas?
The User-Agent header would be a good place to start.
Dec 01 2014
prev sibling next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 2 December 2014 at 00:13:03 UTC, Andrei Alexandrescu 
wrote:
 I wonder if there's some way to filter out robots, build 
 machines etc. Ideas?
We should probably do something to identify all the downloads coming from Travis-CI and other CI solutions.
Dec 01 2014
prev sibling next sibling parent "MattCoder" <stopthespam mail.com> writes:
On Tuesday, 2 December 2014 at 00:13:03 UTC, Andrei Alexandrescu 
wrote:
 One interesting tidbit is that downloads have been rising 
 sharply through mid-November, to have a bit of a pullback 
 recently: http://erdani.com/d/downloads.daily.png
One note about this: I'm using D in my projects since last year, but I'm still using DMD version 2.060! So what I think that would be nice is to find a way to measure the user base beyond the downloads. But anyway nice to see the number of downloads are rising, I hope that means new users. PS: Sorry my english! Matheus.
Dec 01 2014
prev sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Tuesday, 2 December 2014 at 00:13:03 UTC, Andrei Alexandrescu 
wrote:
 On 11/29/14 8:09 AM, bearophile wrote:
 H. S. Teoh:

 Huh??! I *really* don't know what you're talking about, 
 because in the
 last few months, I've seen a dramatic *increase* in Phobos 
 activity.
OK, if I was mistaken then I am happy ::) Sometimes it's good to be wrong.
Might be because my participation has been scarce lately (busy with work and family). I'll also be out at the YOW conference (http://yowconference.com.au), talking about D. One interesting tidbit is that downloads have been rising sharply through mid-November, to have a bit of a pullback recently: http://erdani.com/d/downloads.daily.png I wonder if there's some way to filter out robots, build machines etc. Ideas? Andrei
Just a thought but, its pretty close to end of year. Projects will be slowing down/stopping ext. People going on holiday. That also could screw the results a lot.
Dec 01 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2014 6:19 PM, Rikki Cattermole wrote:
 Just a thought but, its pretty close to end of year. Projects will be slowing
 down/stopping ext. People going on holiday. That also could screw the results a
 lot.
In many organizations, nothing happens from Thanksgiving to the New Years.
Dec 01 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 2/12/2014 3:26 p.m., Walter Bright wrote:
 On 12/1/2014 6:19 PM, Rikki Cattermole wrote:
 Just a thought but, its pretty close to end of year. Projects will be
 slowing
 down/stopping ext. People going on holiday. That also could screw the
 results a
 lot.
In many organizations, nothing happens from Thanksgiving to the New Years.
I guess things are a little different here in New Zealand, but then again different hemisphere. E.g. we legally get Christmas day as a public holiday and schools already ended for the year.
Dec 01 2014
parent Matt Soucy <msoucy csh.rit.edu> writes:
On 12/01/2014 09:31 PM, Rikki Cattermole wrote:
 On 2/12/2014 3:26 p.m., Walter Bright wrote:
 On 12/1/2014 6:19 PM, Rikki Cattermole wrote:
 Just a thought but, its pretty close to end of year. Projects will be=
 slowing
 down/stopping ext. People going on holiday. That also could screw the=
 results a
 lot.
In many organizations, nothing happens from Thanksgiving to the New Ye=
ars.
=20
 I guess things are a little different here in New Zealand, but then aga=
in different hemisphere.
 E.g. we legally get Christmas day as a public holiday and schools alrea=
dy ended for the year. People might "have work", doesn't mean that they get anything done...unle= ss you're my university and decide to give a week of classes and then fin= als, as the only thing between Thanksgiving and Christmas. --=20 Matt Soucy http://msoucy.me/
Dec 02 2014
prev sibling parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 11:37:52 UTC, bearophile wrote:
<snip>
 Some of this "hibernation" could be caused by the latest 
 "revolution" threads by Andrei. But probably there are also 
 other causes.
<snip> Yes, Andrei's ref counting and C++ compatibility, etc. There are choices in debate to push: a) Make D small system lang. b) or Keep D large I say there is more choices: c) Both! Split it like linux: kernal and GNU. kernal is of no use w/ out cd and cat, etc. This way people like Andrei can help even people that use D on real projects. In C++ we have active downstream, ex: http://pocoproject.org/features.html. D gets stronger because of Vibe.d. That can be encourage by spliting/reducing D 'core' to be near useless, w/o a lib for key needed features that are in pre-compiler and downstream ecosystem. Win/win. Andrei's of the world could and should be encouraged as the 'GNU' of D. I am saying 90% of 'D' should be in 'Andrei' domain and all the sacred cows. I'd call the non-core 'D' 'frontal lobe', the part that thinks and D 'core' the 'lizard brain' that is just primitive/visceral. Else the endless debate of large vs small. I say both. Cheers, Vic
Nov 29 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 28, 2014 at 03:33:51PM -0800, Walter Bright via Digitalmars-d wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added to the
 dub registry. The last time it compiled was 2 years ago.
 
 I wound up with at least a dozen references to Phobos names that have
 disappeared. No corrective action was indicated, just "undefined
 symbol". I have to go refigure out what the code was trying to do, and
 go poking through the Phobos documentation to see what will work
 today.
 
 I know there's been a lot of "break my code" advocacy lately, but this
 code was only 2 years old.
 
 I fully understand how unfriendly this is to users and how
 discouraging it can be to have their recently working code shattered
 and scattered. We need to do a lot better.
I think we may have been a little trigger-happy in implementing the deprecation cycle. While technically the deprecation cycle lasts 2 years (?), I think it's probably a good idea to keep deprecated symbols around for far longer than that. You never know when somebody decides to dust off some 5-y.o. code that references an obscure Phobos symbol that has since been deleted after a full deprecation cycle. Perhaps what we need is, after a symbol has passed the deprecation cycle, replace its original definition with a static assert(0). Something like this: // Original implementation: /** * Original docs */ auto mySymbol(A...)(A args) { /* original implementation */ } // Some time later we decide to deprecate it. Before marking it // deprecated, label it with a big fat warning: /** * Original docs * * Warning: This function is slated for deprecation by May 2015. */ auto mySymbol(A...)(A args) { /* original implementation */ } // Afterwards, the deprecated tag is added (ddocs are removed so // that new users will stop using it). deprecated("Please use myOtherSymbol instead.") auto mySymbol(A...)(A args) { /* original implementation */ } // Full deprecation cycle passes. Using this symbol should now // be an error, even if -d is being used. But don't delete it // just yet: deprecated("Please use myOtherSymbol instead.") auto mySymbol(A...)(A args) { static assert(0, "Please use myOtherSymbol instead."); } // After a REALLY long time, I dunno, maybe 4 years? 5 years? // We can finally remove it. This does mean, though, that once released, symbols will stick around for a LONG time, which means some overloads cannot be used if it conflicts with a deprecated symbol, etc.. So std.experimental becomes even more important, to sort out APIs before they essentially get frozen in stone and need >=5 years of proverbial laser scrubbing before they can be erased again. There's also the issue of symbols being moved into a different module -- existing code will expect to find it in the old place, so any aliases / public imports / etc., will have to stay around for quite a long time before they can be gotten rid of. Ditto for currently monolithic modules that eventually gets split into saner-sized chunks. T -- Acid falls with the rain; with love comes the pain.
Nov 28 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 3:53 PM, H. S. Teoh via Digitalmars-d wrote:
 I think we may have been a little trigger-happy in implementing the
 deprecation cycle. While technically the deprecation cycle lasts 2 years
 (?), I think it's probably a good idea to keep deprecated symbols around
 for far longer than that. You never know when somebody decides to dust
 off some 5-y.o. code that references an obscure Phobos symbol that has
 since been deleted after a full deprecation cycle.
And, when they are removed for good, there needs to be section in the phobos module documentation that gives a list of gone names and corresponding new names. If the hapless coder greps for "fnmatch", there are no hits in Phobos. I don't so much mind the name change as I mind not knowing "how do I fix it?". Even if I find a new name, such as "fnmatch" seems to have been replaced with "globMatch", I'm not so sure it has the same behavior. In not one of the cases of changed Phobos names was corrective action presented. (The spell checker suggested replacement names, but was always wrong.) In most of the cases where the language changed, the compiler produced correct corrective action advice.
Nov 28 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.2435.1417218926.9932.digitalmars-d puremagic.com...

 Perhaps what we need is, after a symbol has passed the deprecation
 cycle, replace its original definition with a static assert(0).
 Something like this:
I think disabled with a custom message would be perfect for this. static assert only works for templates.
Nov 28 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 29 November 2014 at 00:20:38 UTC, Daniel Murphy 
wrote:
 I think  disabled with a custom message would be perfect for 
 this.  static assert only works for templates.
We just need someone to implement this. https://issues.dlang.org/show_bug.cgi?id=8728
Nov 29 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Martin Nowak"  wrote in message 
news:znsbjqmgwegyrtvxqmhd forum.dlang.org...

 We just need someone to implement this.
 https://issues.dlang.org/show_bug.cgi?id=8728
Exactly. I've had a look at it a couple of times but never made it past the parser.
Nov 29 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 29 Nov 2014 14:00:49 +0000
Martin Nowak via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Saturday, 29 November 2014 at 00:20:38 UTC, Daniel Murphy=20
 wrote:
 I think  disabled with a custom message would be perfect for=20
 this.  static assert only works for templates.
=20 We just need someone to implement this. https://issues.dlang.org/show_bug.cgi?id=3D8728
and then it will rot in bugzilla forever.
Nov 29 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ketmar:

 and then it will rot in bugzilla forever.
Not necessarily. Some things rot there, but I've seen hundreds of nice patches being merged. Bye, bearophile
Nov 29 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 29 Nov 2014 19:28:00 +0000
bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 ketmar:
=20
 and then it will rot in bugzilla forever.
=20 Not necessarily. Some things rot there, but I've seen hundreds of=20 nice patches being merged.
this one is not pre-approved, so it will not get any attention.
Nov 29 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 17:43:16 -0600
Brad Roberts via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/28/14, 5:39 PM, ketmar via Digitalmars-d wrote:
 oh, wait... such tool was suggested years ago and has no signs of
 "official blessing" until this year's summer! and now it can't fix
 two-year-old code.
=20 I don't understand this attitude. Don't wait for any sort of gold star r=
ubber stamp ticker tape=20
 parade.  If you think something is worth doing, do it.
writing and *supporting* such tool (linter, fixer) which is inevitably tied to the compiler and stdlib development process is a hard work. the author of the tool wants to be sure that this tool is "blessed", so he can interop with other teams. users of such tool wants to be sure that this is not the "one man work" which can disappear any time when author becomes bored. actually, such tool is a part of the compiler suite. that's why it's very little motivation to do it without "blessing". someone can write some quickhack tool for himself to fix *his* codebase, but making such tool usable for others, documenting it and so on is a great amount of work. see, i have the tool that fixes my dmd code for gdc. it successfully processes all my code, 'cause i know my coding habits and can do this with simple regexps. can this tool be used by someone else, on very different codebase? i doubt it. can it be fixed to process other codebases? i doubt it, it doesn't even have the proper parser. do i motivated to improve it? not at all. "blessing" is a motivation. like, say, D->C++ translator which i suggested in the thread about bootstraping D compiler which is written in D. the answer was "no, it's unlikely to be accepted". do i want to spend alot of my time on the code that i myself don't need at all, and without any hope that it will be used later? nope. i have alot of things to code that are interesting for me. "blessing" for companion tools is a motivator.
Nov 28 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added 
 to the dub registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names 
 that have disappeared.
Only 12? That's pretty damn good. No corrective action was indicated, just
 "undefined symbol". I have to go refigure out what the code was 
 trying to do, and go poking through the Phobos documentation to 
 see what will work today.

 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.
I don't expect any 2 year old software to work with the latest tools. All of my products are tied to the compiler they are built with. I don't upgrade until I'm ready to allocate resources to refactoring and testing. I'm still using Visual Studio 6.0 on some projects.
 I fully understand how unfriendly this is to users and how 
 discouraging it can be to have their recently working code 
 shattered and scattered. We need to do a lot better.
Users' migration to the latest tools is in their hands to handle how they wish. It's their responsibility. * They don't have to upgrade. * There are beta cycles for them to test with to mitigate risk and inform maintainers of problems. * The project is open source, and developed right out in the open, so all changes are documented, the source code is available, and users have the opportunity to influence the outcome. * Each version is segregated into its own branch, and with diff tools, all changes can be seen relatively easily. * I could go on. I'm not buying the argument that D shouldn't evolve because users are carelessly upgrading their tools and expecting everything to just work. Mike
Nov 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 5:27 PM, Mike wrote:
 On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added to the dub
 registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names that have
 disappeared.
Only 12? That's pretty damn good.
It's a pretty small program, 5000 lines.
Nov 28 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Just for fun, I've decided to try and [...]
There's a pull in need of some love, I'd like to see this in D: https://github.com/D-Programming-Language/dmd/pull/3615 Bye, bearophile
Nov 28 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 29 Nov 2014 01:39:44 +0000
bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Walter Bright:
=20
 Just for fun, I've decided to try and [...]
=20 There's a pull in need of some love, I'd like to see this in D: https://github.com/D-Programming-Language/dmd/pull/3615
it needs just some cosmetix changes (afair) and that's all. i'm using this patch from july and still alive. ;-)
Nov 28 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 29, 2014 at 04:12:05AM +0200, ketmar via Digitalmars-d wrote:
 On Sat, 29 Nov 2014 01:39:44 +0000
 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 
 Walter Bright:
 
 Just for fun, I've decided to try and [...]
There's a pull in need of some love, I'd like to see this in D: https://github.com/D-Programming-Language/dmd/pull/3615
I'd like to see this in D too. AFAICT, everybody else has approved it, it's just Walter who has some reservations about it.
 it needs just some cosmetix changes (afair) and that's all. i'm using
 this patch from july and still alive. ;-)
What kind of cosmetic changes are needed? T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
Nov 28 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 18:15:30 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 On Sat, Nov 29, 2014 at 04:12:05AM +0200, ketmar via Digitalmars-d wrote:
 On Sat, 29 Nov 2014 01:39:44 +0000
 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:
=20
 Walter Bright:
=20
 Just for fun, I've decided to try and [...]
=20 There's a pull in need of some love, I'd like to see this in D: https://github.com/D-Programming-Language/dmd/pull/3615
=20 I'd like to see this in D too. AFAICT, everybody else has approved it, it's just Walter who has some reservations about it. =20 =20
 it needs just some cosmetix changes (afair) and that's all. i'm using
 this patch from july and still alive. ;-)
=20 What kind of cosmetic changes are needed?
i honestly can't remember. can't diff my version with original patch from github 'cause my version has alot of code style changes which makes diff spit out almost any line. that was really some cosmetic changes a-la "this line was split to two, so path can't find it anymore" and so on, nothing intrusive. i don't even sure that those cosmetic changes was not caused by my other patches.
Nov 28 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
This is more of an Ubuntu-y issue, but I'm having trouble getting it to link 
with ncurses. This used to work:

cc $(LDFLG)  -o med $(OBJ) -l :libncurses.so.5 -l phobos2 -l pthread -l m

but alas, no longer with the latest Ubuntu. (Linux people keep trying to get
rid 
of termcap, it's a constant issue.) -lncurses fails, everything I try fails.

Any ideas?
Nov 28 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 28, 2014 at 05:55:21PM -0800, Walter Bright via Digitalmars-d wrote:
 This is more of an Ubuntu-y issue, but I'm having trouble getting it
 to link with ncurses. This used to work:
 
 cc $(LDFLG)  -o med $(OBJ) -l :libncurses.so.5 -l phobos2 -l pthread -l m
 
 but alas, no longer with the latest Ubuntu. (Linux people keep trying
 to get rid of termcap, it's a constant issue.) -lncurses fails,
 everything I try fails.
 
 Any ideas?
Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try `apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate). Otherwise, try -lncurses5 or -lncursesw5, perhaps? T -- Don't modify spaghetti code unless you can eat the consequences.
Nov 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2014 6:08 PM, H. S. Teoh via Digitalmars-d wrote:
 Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try
 `apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate).
 Otherwise, try -lncurses5 or -lncursesw5, perhaps?
Yeah, that didn't work, either. I wound up simply ripping out ncurses and hardcoding it for xterm.
Nov 29 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 29 Nov 2014 00:41:45 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/28/2014 6:08 PM, H. S. Teoh via Digitalmars-d wrote:
 Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try
 `apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate).
 Otherwise, try -lncurses5 or -lncursesw5, perhaps?
=20 Yeah, that didn't work, either. =20 I wound up simply ripping out ncurses and hardcoding it for xterm.
hm. it took me ~30 minutes to fix all the warnings and build it succesfully with ncurses, both with dmd head and gdc...
Nov 29 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 29 Nov 2014 00:41:45 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/28/2014 6:08 PM, H. S. Teoh via Digitalmars-d wrote:
 Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try
 `apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate).
 Otherwise, try -lncurses5 or -lncursesw5, perhaps?
=20 Yeah, that didn't work, either. =20 I wound up simply ripping out ncurses and hardcoding it for xterm.
ah, yes, i'm lazy, so i ripped off ^Z and one scrolling optimisation. it can be fixed easily, but i don't see any sense in it.
Nov 29 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 29, 2014 at 12:41:45AM -0800, Walter Bright via Digitalmars-d wrote:
 On 11/28/2014 6:08 PM, H. S. Teoh via Digitalmars-d wrote:
Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try
`apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate).
Otherwise, try -lncurses5 or -lncursesw5, perhaps?
Yeah, that didn't work, either. I wound up simply ripping out ncurses and hardcoding it for xterm.
Haha... obviously you haven't seen Adam Ruppe's excellent terminal.d library: https://github.com/adamdruppe/arsd I used it for a few of my own projects, and it's pretty awesome. Not perfect, mind you, but it does work pretty well for common terminals like xterm (or whatever termcap entries it can parse). I highly recommend it. T -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Nov 29 2014
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 17:55:21 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 This is more of an Ubuntu-y issue, but I'm having trouble getting it to l=
ink=20
 with ncurses. This used to work:
=20
 cc $(LDFLG)  -o med $(OBJ) -l :libncurses.so.5 -l phobos2 -l pthread -l m
=20
 but alas, no longer with the latest Ubuntu. (Linux people keep trying to =
get rid=20
 of termcap, it's a constant issue.) -lncurses fails, everything I try fai=
ls.
=20
 Any ideas?
this is the tcap.d issue. first: move `char PC;` and `short ospeed;` out of `extern(C)` (that is what drives ld mad). second: kill that linker command and replace it with: gcc $(LDFLG) -o med $(OBJ) -lncurses -lphobos2 -lpthread -lm -lrt this should be enough.
Nov 28 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 28 Nov 2014 18:08:27 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try
 `apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate).
 Otherwise, try -lncurses5 or -lncursesw5, perhaps?
no need to do that, D doesn't use C ncurses headers.
Nov 28 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 [snip]

 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.

 I fully understand how unfriendly this is to users and how 
 discouraging it can be to have their recently working code 
 shattered and scattered. We need to do a lot better.
With every new release of Visual Studio I expect things to break. Every release I'm right. Every release I spend a day fixing our build for the new Visual Studio. After that I get to enjoy a much nicer compiler (and IDE). Switching from gcc to clang had some sore points but it was well worth the change. Moving to C++11 involved quite a bit of work but again, totally worth it. There is only 2-3 years (and now annual) between Visual Studio releases yet stuff still breaks. This is with C++ where you expect rigid backward compatibility. I have no expectation of that with D (as much as we'd all like to stamp it "stable" for marketing purposes). If a project is stagnant (no updates in years) I have no delusions that it will work without issue using the latest compilers/interpreters (regardless of language). It's a nice fantasy to think we could have it that way but it just doesn't exist.
Nov 29 2014
prev sibling next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.
I've lost my faith in expecting to see the D core team grasp what the so called "break my code" folks aims to reach. -- Paolo
Nov 29 2014
parent "Vic" <vic.cvc gmx.com> writes:
On Saturday, 29 November 2014 at 11:35:52 UTC, Paolo Invernizzi
wrote:
 On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright 
 wrote:
 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.
I've lost my faith in expecting to see the D core team grasp what the so called "break my code" folks aims to reach. -- Paolo
Yup.
Nov 29 2014
prev sibling next sibling parent reply Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 11/29/14, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added to the dub
 registry. The last time it compiled was 2 years ago.
You seem to create this kind of thread every other month. People complaint to you about A and B, you ignore it, and then when it hits you *personally* suddenly it's a shock to you. The fact that you think you're going to get symbol suggestions for 2 year old code just shows how out of touch you are with the development process. We have a deprecation stage, and a removal stage. There's no way you're going to get suggestions for missing symbols for code that references those symbols which existed 2 years ago. /rant-mode activated
Nov 29 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2014 7:56 AM, Andrej Mitrovic via Digitalmars-d wrote:
 On 11/29/14, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added to the dub
 registry. The last time it compiled was 2 years ago.
You seem to create this kind of thread every other month. People complaint to you about A and B, you ignore it, and then when it hits you *personally* suddenly it's a shock to you. The fact that you think you're going to get symbol suggestions for 2 year old code just shows how out of touch you are with the development process. We have a deprecation stage, and a removal stage. There's no way you're going to get suggestions for missing symbols for code that references those symbols which existed 2 years ago.
Since I participate in that process, I am hardly unaware of it :-)
Nov 29 2014
prev sibling next sibling parent "David Soria Parra" <davidsp fb.com> writes:
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added 
 to the dub registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names 
 that have disappeared. No corrective action was indicated, just 
 "undefined symbol". I have to go refigure out what the code was 
 trying to do, and go poking through the Phobos documentation to 
 see what will work today.

 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.

 I fully understand how unfriendly this is to users and how 
 discouraging it can be to have their recently working code 
 shattered and scattered. We need to do a lot better.
To be fair, this is already a minor annoyance between every DMD release, that I have to go through existing D code and fix all the nits, which are mostly phobos backwards compatibility breaks. This is making it hard to advocate to write more code in D. It's been a while since I had to do that the last time with a new gcc or libc release.
Nov 29 2014
prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added 
 to the dub registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names 
 that have disappeared. No corrective action was indicated, just 
 "undefined symbol". I have to go refigure out what the code was 
 trying to do, and go poking through the Phobos documentation to 
 see what will work today.

 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.

 I fully understand how unfriendly this is to users and how 
 discouraging it can be to have their recently working code 
 shattered and scattered. We need to do a lot better.
Why are deprecated aliases even removed in the first place? Is there any harm in keeping them for 5+ years (undocumented of course)? There isn't any increased complexity for the user, you can completely ignore them during development, and if needed they could just go to the bottom of the scope/file hidden away from the rest of the code.
Nov 29 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 29, 2014 at 08:32:37PM +0000, Kapps via Digitalmars-d wrote:
 On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
Just for fun, I've decided to try and get MicroEmacs in D added to
the dub registry. The last time it compiled was 2 years ago.

I wound up with at least a dozen references to Phobos names that have
disappeared. No corrective action was indicated, just "undefined
symbol".  I have to go refigure out what the code was trying to do,
and go poking through the Phobos documentation to see what will work
today.

I know there's been a lot of "break my code" advocacy lately, but
this code was only 2 years old.

I fully understand how unfriendly this is to users and how
discouraging it can be to have their recently working code shattered
and scattered. We need to do a lot better.
Why are deprecated aliases even removed in the first place? Is there any harm in keeping them for 5+ years (undocumented of course)? There isn't any increased complexity for the user, you can completely ignore them during development, and if needed they could just go to the bottom of the scope/file hidden away from the rest of the code.
Yeah we should keep deprecated aliases around for much longer than we currently do. Having said that, though, there *are* some cases where we can't keep an old symbol around, e.g., it causes conflicts with newer overloads. But that shouldn't be a problem in this case, as it'd be clear that that particular function now requires different arguments, whereas Walter was complaining about symbols that vanished into thin air without a clue as to where they went. There's also the issue of symbols that got moved to a different module. Sometimes leaving an alias behind is not workable, because it will cause conflicts when user code imports both modules. Unless, of course, we change overload rules to allow such apparent conflicts when they actually ultimately resolve to the same symbol in the end. T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
Nov 29 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2014 1:56 PM, H. S. Teoh via Digitalmars-d wrote:
 There's also the issue of symbols that got moved to a different module.
 Sometimes leaving an alias behind is not workable, because it will cause
 conflicts when user code imports both modules. Unless, of course, we
 change overload rules to allow such apparent conflicts when they
 actually ultimately resolve to the same symbol in the end.
Aliases that resolve to the same symbol was a bug fixed long ago. If this has resurfaced, please file a bugzilla.
Nov 29 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Nov 29, 2014 at 02:24:46PM -0800, Walter Bright via Digitalmars-d wrote:
 On 11/29/2014 1:56 PM, H. S. Teoh via Digitalmars-d wrote:
There's also the issue of symbols that got moved to a different
module.  Sometimes leaving an alias behind is not workable, because
it will cause conflicts when user code imports both modules. Unless,
of course, we change overload rules to allow such apparent conflicts
when they actually ultimately resolve to the same symbol in the end.
Aliases that resolve to the same symbol was a bug fixed long ago. If this has resurfaced, please file a bugzilla.
Ah, so I'm outdated. That's good to know. :-) T -- What doesn't kill me makes me stranger.
Nov 29 2014
prev sibling next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added 
 to the dub registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names 
 that have disappeared. No corrective action was indicated, just 
 "undefined symbol". I have to go refigure out what the code was 
 trying to do, and go poking through the Phobos documentation to 
 see what will work today.

 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.

 I fully understand how unfriendly this is to users and how 
 discouraging it can be to have their recently working code 
 shattered and scattered. We need to do a lot better.
I've just made xmlp (http://www.dsource.org/projects/xmlp) compile with the newest version of D. It wasn't that bad, despite xmlp rotting for two years with merge markers left in it. However what would have made this even easier, would be a) a summary for each release called "How this version breaks your code and how to fix it". Don't need that for library changes, language changes are enough. b) easy access to older versions of the documentation. When you have a deprecated and subsequently removed function, you should at least be able to lookup what the code was supposed to do.
Nov 30 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Nov 30, 2014 at 12:15:48PM +0000, Tobias Pankrath via Digitalmars-d
wrote:
[...]
 I've just made xmlp (http://www.dsource.org/projects/xmlp) compile
 with the newest version of D. It wasn't that bad, despite xmlp rotting
 for two years with merge markers left in it. However what would have
 made this even easier, would be
 
 a) a summary for each release called "How this version breaks your
 code and how to fix it". Don't need that for library changes, language
 changes are enough.
I thought dlang.org already has a page that lists language & library changes for each of the recent releases? Those lists tend to be pretty long, though, which means people aren't likely to actually read it all. I wonder if there are other ways of navigating them so that they are actaully useful.
 b) easy access to older versions of the documentation. When you have a
 deprecated and subsequently removed function, you should at least be
 able to lookup what the code was supposed to do.
[...] Good idea! We should archive docs from older versions of Phobos and make them accessible on dlang.org. I'm working on revamping some parts of the Phobos docs build; once that's in, it might not be too hard to make it also generate docs for older releases. T -- What do you call optometrist jokes? Vitreous humor.
Nov 30 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
 Good idea! We should archive docs from older versions of Phobos and make
 them accessible on dlang.org. I'm working on revamping some parts of the
 Phobos docs build; once that's in, it might not be too hard to make it
 also generate docs for older releases.
I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(
Nov 30 2014
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
30-Nov-2014 23:22, Walter Bright пишет:
 On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
 Good idea! We should archive docs from older versions of Phobos and make
 them accessible on dlang.org. I'm working on revamping some parts of the
 Phobos docs build; once that's in, it might not be too hard to make it
 also generate docs for older releases.
I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(
Even back in 2010 it took about 10 evenings to get it to "runnable" state. Then another ~20 evenings to fix most of bugs, including semantic errors and GC collecting live objects. You may want to check my fork that used to compile with dmd 2.058 or smth (whatever was actual in 2012). Might help to assess the amount of work... https://github.com/DmitryOlshansky/DMDScript It at least passed about 90% (most fails in library tests) of 2012 Google's Spuntik JavaScript test. -- Dmitry Olshansky
Nov 30 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2014 12:28 PM, Dmitry Olshansky wrote:
 30-Nov-2014 23:22, Walter Bright пишет:
 On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
 Good idea! We should archive docs from older versions of Phobos and make
 them accessible on dlang.org. I'm working on revamping some parts of the
 Phobos docs build; once that's in, it might not be too hard to make it
 also generate docs for older releases.
I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(
Even back in 2010 it took about 10 evenings to get it to "runnable" state. Then another ~20 evenings to fix most of bugs, including semantic errors and GC collecting live objects. You may want to check my fork that used to compile with dmd 2.058 or smth (whatever was actual in 2012). Might help to assess the amount of work... https://github.com/DmitryOlshansky/DMDScript It at least passed about 90% (most fails in library tests) of 2012 Google's Spuntik JavaScript test.
Wow, I didn't know you'd done this. I'll check it out. I know that the D1 version did pass Sun's Javascript test suite which was vintage 2000 or so. My intent after updating DMDScript is to put it on dub.
Nov 30 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2014 12:28 PM, Dmitry Olshansky wrote:
 30-Nov-2014 23:22, Walter Bright пишет:
 On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
 Good idea! We should archive docs from older versions of Phobos and make
 them accessible on dlang.org. I'm working on revamping some parts of the
 Phobos docs build; once that's in, it might not be too hard to make it
 also generate docs for older releases.
I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(
Even back in 2010 it took about 10 evenings to get it to "runnable" state. Then another ~20 evenings to fix most of bugs, including semantic errors and GC collecting live objects. You may want to check my fork that used to compile with dmd 2.058 or smth (whatever was actual in 2012). Might help to assess the amount of work... https://github.com/DmitryOlshansky/DMDScript It at least passed about 90% (most fails in library tests) of 2012 Google's Spuntik JavaScript test.
Do you mind if I simply merge your fork into https://github.com/DigitalMars/DMDScript ?
Nov 30 2014
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
01-Dec-2014 01:44, Walter Bright пишет:
 On 11/30/2014 12:28 PM, Dmitry Olshansky wrote:
 30-Nov-2014 23:22, Walter Bright пишет:
 On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
 Good idea! We should archive docs from older versions of Phobos and
 make
 them accessible on dlang.org. I'm working on revamping some parts of
 the
 Phobos docs build; once that's in, it might not be too hard to make it
 also generate docs for older releases.
I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(
Even back in 2010 it took about 10 evenings to get it to "runnable" state. Then another ~20 evenings to fix most of bugs, including semantic errors and GC collecting live objects. You may want to check my fork that used to compile with dmd 2.058 or smth (whatever was actual in 2012). Might help to assess the amount of work... https://github.com/DmitryOlshansky/DMDScript It at least passed about 90% (most fails in library tests) of 2012 Google's Spuntik JavaScript test.
Do you mind if I simply merge your fork into https://github.com/DigitalMars/DMDScript ?
Not at all, in fact, that would be awesome. -- Dmitry Olshansky
Nov 30 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I decided to try and update DMDScript from D1 to D2. Thousands 
 and thousands of error messages :-(
It's not just the errors, it's also the new features and opportunities offered by the newer D/Phobos that you weren't using in the old code... Just removing the errors is usually not enough to produce modern and very good D2 code. Bye, bearophile
Nov 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2014 12:54 PM, bearophile wrote:
 Walter Bright:

 I decided to try and update DMDScript from D1 to D2. Thousands and thousands
 of error messages :-(
It's not just the errors, it's also the new features and opportunities offered by the newer D/Phobos that you weren't using in the old code... Just removing the errors is usually not enough to produce modern and very good D2 code.
I'm aware that D2 offers many opportunities to improve the code :-) After all, DMDScript is a very early D project.
Nov 30 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I'm aware that D2 offers many opportunities to improve the code 
 :-)
One problem I am seeing is that there is a large distance from the bare-bones code D2 requires you to write, and the code that I now regard as good D2 code. And the D2 compiler doesn't require or pushes you much toward the better code. You can see that even for in the smallest things, like: foreach (i; 0 .. 10) { writeln(i); i++; writeln(i); } I suggested to make that variable i an immutable by default. Currently it's a mutable and nearly no one bothers to write the correct and safer code: foreach (immutable i; 0 .. 10) { writeln(i); writeln(i + 1); } The moral of this story is that a language needs to be designed to have by default the best&safe idioms (but avoiding excessive amounts of typing as Ada). This is a hard balance to find. Here you can see two examples of code that show the difference from the C-style code that compiles with D2, and the code you can write in D2 only if you push yourself a lot to express more invariants and more precise typing: http://rosettacode.org/wiki/Hidato#D (The two programs are similar but they don't do exactly the same things. The second program is longer also because it does a little more). Most of the D code you see in the wild is the C-like code of the first kind. This problem is present even in Ada code or F# code, but in F# the "basic" style of coding is rather safer than D written in the bare bones C-style, and it's rather crisp. Bye, bearophile
Nov 30 2014
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 30 November 2014 at 23:16:14 UTC, bearophile wrote:
 ...
 I suggested to make that variable i an immutable by default.
I suggest everything be made immutable by default ;)
Nov 30 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
weaselcat:

 On Sunday, 30 November 2014 at 23:16:14 UTC, bearophile wrote:
 ...
 I suggested to make that variable i an immutable by default.
I suggest everything be made immutable by default ;)
Currently D doesn't have a keyword as "mut" or "mutable" so if you make the foreach variable immutable by default, you have some troubles when (rarely) you want a mutable foreach index (you need an auxiliary variable, and you have to type it manually, because if you use "auto" you get another immutable again). But for the general case of all the variables, this breaks all the D2 code, so you can't do that (but I don't know why this change wasn't done in the D1->D2 transition), and I think Walter doesn't like things like pragma(strict) to be put beside the module name to denote modules where variables are const/immutable by default. So I didn't even discuss this impossible option. Bye, bearophile
Nov 30 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, November 30, 2014 23:19:19 weaselcat via Digitalmars-d wrote:
 I suggest everything be made immutable by default ;)
That probably would have been too much of a divergence from D's C/C++ roots to go over very well, but it's something that we would probably consider if we were starting from scratch - similarly, pure and safe should probably be the default for functions, but it's far too late now. - Jonathan M Davis
Nov 30 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Nov 30, 2014 at 08:52:33PM -0800, Jonathan M Davis via Digitalmars-d
wrote:
 On Sunday, November 30, 2014 23:19:19 weaselcat via Digitalmars-d wrote:
 I suggest everything be made immutable by default ;)
That probably would have been too much of a divergence from D's C/C++ roots to go over very well, but it's something that we would probably consider if we were starting from scratch - similarly, pure and safe should probably be the default for functions, but it's far too late now.
[...] If we were ever to have a D3, I'd propose that one of the first things to do is to make everything pure and safe by default. T -- Leather is waterproof. Ever see a cow with an umbrella?
Nov 30 2014
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Nov 30, 2014 at 12:22:54PM -0800, Walter Bright via Digitalmars-d wrote:
 On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
Good idea! We should archive docs from older versions of Phobos and
make them accessible on dlang.org. I'm working on revamping some
parts of the Phobos docs build; once that's in, it might not be too
hard to make it also generate docs for older releases.
I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(
Well... upgrading from C to C++ involves... close to zero error messages. But that's not necessarily a good thing, as I'm sure you'll agree! I think in many ways, D2 is a far different language than D1, and it'd be unrealistic to expect D1 code to compile with D2 without a fair amount of changes. T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
Nov 30 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-11-30 16:36, H. S. Teoh via Digitalmars-d wrote:

 I thought dlang.org already has a page that lists language & library
 changes for each of the recent releases?
We have only had that for a couple of releases and not the latest release. No one wrote that document for the latest release and it, apparently, was more important to get the new release out. Also, they only list changes. There's no indication if it's a breaking change or not.
 Good idea! We should archive docs from older versions of Phobos and make
 them accessible on dlang.org. I'm working on revamping some parts of the
 Phobos docs build; once that's in, it might not be too hard to make it
 also generate docs for older releases.
Yeah, it needs to be possible to access the documentation for an arbitrary version of D at dlang.org. -- /Jacob Carlborg
Dec 01 2014
prev sibling next sibling parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/11/14 16:56, Andrej Mitrovic via Digitalmars-d wrote:
 The fact that you think you're going to get symbol suggestions for 2
 year old code just shows how out of touch you are with the development
 process. We have a deprecation stage, and a removal stage. There's no
 way you're going to get suggestions for missing symbols for code that
 references those symbols which existed 2 years ago.
It's fair to say that 2 years is a long time in recent Phobos development. However, I don't think Walter's point is about it biting him personally. The question is, what happens if somebody tries to use or resurrect an old D project -- how much trouble are they going to have trying to bring it back to life, and where they need to update code, how helpful are the tools? It doesn't reflect well on the language or its community if older D code is as unusable as Walter describes, and it's particularly problematic where it relates to Phobos, because here we have much more scope to deprecate things without ever actually removing them. That said, I don't think this is an argument for freezing things. I think it's an argument for being very clear about what parts of the Phobos API are stable, and allowing for the (clearly documented) possibility of change where that may be desirable.
Nov 30 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sunday, November 30, 2014 07:28:57 H. S. Teoh via Digitalmars-d wrote:
 On Sun, Nov 30, 2014 at 03:03:23AM -0800, Jonathan M Davis via Digitalmars-d
wrote:
 To really have full stability, we'd pretty much have to freeze
 everything and change nothing beyond bug fixes, and we're definitely
 not doing that. Heck, simply introducing a new function to Phobos can
 break existing code, because it can create a symbol conflict.
Speaking of which, this problem is made a lot worse than it could be, because currently private symbols in imported modules are included in the overload set, so introducing a *private* symbol can break unrelated user code downstream. Ugh.
Yeah, and AFAIK, no one ever managed to convince Walter that that needed to be changed. There were DIPs on the matter, but I don't recall if any made it to the PR stage or not. I know that Martin was looking at it at one point, and he wrote one of the DIPs, but AFAIK, he hasn't touched the issue recently.
 It's an easy fix, but stuff like that makes it nigh on impossible to
 guarantee that we won't break two-year old code.
[...] I think the complaint was not so much the fact that the code broke, but the fact that it broke *without any clue as to how to fix it*. Now, if we had something like disable with an optional message, we could do something like: disabled("Please use globMatch instead") auto fnmatch(...); At least in theory, this would fix the problem. Of course, in practice, things rarely work out so nicely except in retrospect. :-P
That would create symbol conflicts as long as the symbol was kept around, which is more of a problem in some cases than others. It also leaves cruft in the library. So, ideally, we wouldn't leave stuff like that around, but as the language and standard library mature, we are going to need to seriously look at having two year old code work with an up-to-date compiler and standard library. Thus far, the approach has been that folks really need to be maintaining their code at least occasionally, and we've supported moving code forward clearly via the deprecation cycle, but code that isn't touched for years wasn't really even considered a legitimate use case by many of us - and yebblie's suggestion of updating to an intermediary compiler does solve the problem rather nicely. So, I don't know. As a maintainer of Phobos, I'd much prefer to not leave cruft around, since it does make the library worse for anyone who is maintaining their code, and I don't know how much sympathy I have when code isn't even built with a newer compiler for over two years. But we do want to be a lot more stable than we are... Maintaining stability while avoiding stagnation and cruft is always a challenge. - Jonathan m Davis
Dec 01 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-11-29 00:33, Walter Bright wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added to the
 dub registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names that have
 disappeared. No corrective action was indicated, just "undefined
 symbol". I have to go refigure out what the code was trying to do, and
 go poking through the Phobos documentation to see what will work today.

 I know there's been a lot of "break my code" advocacy lately, but this
 code was only 2 years old.

 I fully understand how unfriendly this is to users and how discouraging
 it can be to have their recently working code shattered and scattered.
 We need to do a lot better.
Every single release since at least DMD 2.050 has broken DWT. Most of these issues were language changes and not renamed symbols in Phobos. -- /Jacob Carlborg
Dec 01 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2014 5:36 AM, Jacob Carlborg wrote:
 Every single release since at least DMD 2.050 has broken DWT. Most of these
 issues were language changes and not renamed symbols in Phobos.
My experience with upgrading old D code, even D1 code, is that language changes were easier to deal with than Phobos changes. The reason is because we've done a fairly good job with compiler error messages that not only point out errors, but suggest corrective action.
Dec 01 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-11-29 00:33, Walter Bright wrote:

 I fully understand how unfriendly this is to users and how discouraging
 it can be to have their recently working code shattered and scattered.
 We need to do a lot better.
When we're talking about breaking code, I just found this regression: https://issues.dlang.org/show_bug.cgi?id=13811 -- /Jacob Carlborg
Dec 02 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
 Just for fun, I've decided to try and get MicroEmacs in D added 
 to the dub registry. The last time it compiled was 2 years ago.

 I wound up with at least a dozen references to Phobos names 
 that have disappeared. No corrective action was indicated, just 
 "undefined symbol". I have to go refigure out what the code was 
 trying to do, and go poking through the Phobos documentation to 
 see what will work today.

 I know there's been a lot of "break my code" advocacy lately, 
 but this code was only 2 years old.

 I fully understand how unfriendly this is to users and how 
 discouraging it can be to have their recently working code 
 shattered and scattered. We need to do a lot better.
We have deprecation cycle of one year. Expecting unmaintained application to compile after 2 years has passed is completely unreasonable. Almost every single D program out there breaks with _each_ DMD release, Phobos deprecations are least of all evils there. Try fixing that before complaining about #breakmycode Also it feels like you consider D at stable version. It isn't. There is a huge amount of work to be done before it can be considered even honest 1.0.0 - doing something with scope, finishing nogc / rc attempts, cleaning up qualifier mess etc. Once it is all done, maybe (maybe!) we can talk about stability. Right now it is a fallacy.
Dec 04 2014