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.




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.


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