• Andrei Alexandrescu (9/9) Oct 18 2008 I plan to overhaul a number of modules in Phobos2, such as
• Jason House (2/15) Oct 18 2008 D has a deprecated keyword... Could that be used?
• KennyTM~ (2/20) Oct 19 2008 vote++ for deprecated;
• Janderson (5/27) Oct 20 2008 Perhaps depreciated code could be put under file.deprecated.d (or
• ore-sama (2/6) Oct 18 2008 may be std.old.*?
• Bill Baxter (12/17) Oct 19 2008 A nicer way to do it would be to make it all deprecated (but still
• Moritz Warning (5/14) Oct 19 2008 "etc" doesn't mean deprecated or old in any way in letters or the unix
• Walter Bright (1/1) Oct 19 2008 Your post appeared 5 times, please check your posting software.
• Moritz Warning (3/4) Oct 19 2008 I noticed. Pan (my news reader) took quite some time to send that messag...
• Moritz Warning (5/14) Oct 19 2008 "etc" doesn't mean deprecated or old in any way in letters or the unix
• Moritz Warning (5/14) Oct 19 2008 "etc" doesn't mean deprecated or old in any way in letters or the unix
• Moritz Warning (5/14) Oct 19 2008 "etc" doesn't mean deprecated or old in any way in letters or the unix
• Moritz Warning (5/14) Oct 19 2008 "etc" doesn't mean deprecated or old in any way in letters or the unix
• bearophile (17/19) Oct 19 2008 Regarding std.stdio: the current function writeln() has a large amount o...
• Don (4/12) Oct 19 2008 Since one of the examples given as an aim of the Tango/Phobos merger was...

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

I plan to overhaul a number of modules in Phobos2, such as 
std.algorithm, std.stdio, and std.random. The changes will render 
existing code using those modules largely uncompilable. I wonder what a 
good evolution scheme we should adopt. Walter suggested that I move the 
old modules in etc/, so changing e.g. std.algorithm to etc.algorithm 
should make legacy code work.

Is this agreeable? Are there better possibilities?


Thanks,

Andrei

Jason House <jason.james.house gmail.com> writes:

Andrei Alexandrescu Wrote:

 I plan to overhaul a number of modules in Phobos2, such as 
 std.algorithm, std.stdio, and std.random. The changes will render 
 existing code using those modules largely uncompilable. I wonder what a 
 good evolution scheme we should adopt. Walter suggested that I move the 
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm 
 should make legacy code work.
 
 Is this agreeable? Are there better possibilities?
 
 
 Thanks,
 
 Andrei

D has a deprecated keyword... Could that be used?

KennyTM~ <kennytm gmail.com> writes:

Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 I plan to overhaul a number of modules in Phobos2, such as 
 std.algorithm, std.stdio, and std.random. The changes will render 
 existing code using those modules largely uncompilable. I wonder what a 
 good evolution scheme we should adopt. Walter suggested that I move the 
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm 
 should make legacy code work.

 Is this agreeable? Are there better possibilities?


 Thanks,

 Andrei

 
 D has a deprecated keyword... Could that be used?
 

vote++ for deprecated;

Janderson <ask me.com> writes:

KennyTM~ wrote:
 Jason House wrote:
 Andrei Alexandrescu Wrote:

 I plan to overhaul a number of modules in Phobos2, such as 
 std.algorithm, std.stdio, and std.random. The changes will render 
 existing code using those modules largely uncompilable. I wonder what 
 a good evolution scheme we should adopt. Walter suggested that I move 
 the old modules in etc/, so changing e.g. std.algorithm to 
 etc.algorithm should make legacy code work.

 Is this agreeable? Are there better possibilities?


 Thanks,

 Andrei

 D has a deprecated keyword... Could that be used?

 
 vote++ for deprecated;
 

Perhaps depreciated code could be put under file.deprecated.d (or 
file.dep.d) and included by the new file, along with the deprecated 
word, just to keep things tidy.

-Joel

ore-sama <spam here.lot> writes:

Andrei Alexandrescu Wrote:

 Walter suggested that I move the 
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm 
 should make legacy code work.
 

may be std.old.*?

"Bill Baxter" <wbaxter gmail.com> writes:

On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam here.lot> wrote:
 Andrei Alexandrescu Wrote:

 Walter suggested that I move the
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
 should make legacy code work.


A nicer way to do it would be to make it all deprecated (but still
operational) in one release, then replace it in the next release.

 may be std.old.*?

I like that better than etc.

Maybe even std.deprecate.*
Or
std_deprecated.*
(I think a package name can't be a keyword, right?  If it could then
I'd say std.deprecated.*)

I don't like etc though -- it doesn't imply to me at all that the
stuff inside it would be old and deprecated.

--bb

Moritz Warning <moritzwarning web.de> writes:

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

 On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam here.lot> wrote:
 Andrei Alexandrescu Wrote:

 Walter suggested that I move the
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
 should make legacy code work.



"etc" doesn't mean deprecated or old in any way in letters or the unix 
etc/ folder.

 A nicer way to do it would be to make it all deprecated (but still
 operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

 may be std.old.*?


Sounds good!

Walter Bright <newshound1 digitalmars.com> writes:

Your post appeared 5 times, please check your posting software.

Moritz Warning <moritzwarning web.de> writes:

On Sun, 19 Oct 2008 13:28:28 -0700, Walter Bright wrote:

 Your post appeared 5 times, please check your posting software.

I noticed. Pan (my news reader) took quite some time to send that message.
It worked before. :/

Moritz Warning <moritzwarning web.de> writes:

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

 On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam here.lot> wrote:
 Andrei Alexandrescu Wrote:

 Walter suggested that I move the
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
 should make legacy code work.



"etc" doesn't mean deprecated or old in any way in letters or the unix 
etc/ folder.

 A nicer way to do it would be to make it all deprecated (but still
 operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

 may be std.old.*?


Sounds good!

Moritz Warning <moritzwarning web.de> writes:

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

 On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam here.lot> wrote:
 Andrei Alexandrescu Wrote:

 Walter suggested that I move the
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
 should make legacy code work.



"etc" doesn't mean deprecated or old in any way in letters or the unix 
etc/ folder.

 A nicer way to do it would be to make it all deprecated (but still
 operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

 may be std.old.*?


Sounds good!

Moritz Warning <moritzwarning web.de> writes:

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

 On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam here.lot> wrote:
 Andrei Alexandrescu Wrote:

 Walter suggested that I move the
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
 should make legacy code work.



"etc" doesn't mean deprecated or old in any way in letters or the unix 
etc/ folder.

 A nicer way to do it would be to make it all deprecated (but still
 operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

 may be std.old.*?


Sounds good!

Moritz Warning <moritzwarning web.de> writes:

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

 On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam here.lot> wrote:
 Andrei Alexandrescu Wrote:

 Walter suggested that I move the
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
 should make legacy code work.



"etc" doesn't mean deprecated or old in any way in letters or the unix 
etc/ folder.

 A nicer way to do it would be to make it all deprecated (but still
 operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

 may be std.old.*?


Sounds good!

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:
 I plan to overhaul a number of modules in Phobos2, such as 
 std.algorithm, std.stdio, and std.random.

Regarding std.stdio: the current function writeln() has a large amount of
faults. I have fixed about 20 of them in my put()/putr() and str()/repr()
functions, but not all them. You can copy part of the code of them from my
libs, and I can list some things in this newsgroup.

-------------

Regarding std.random: it has to reconcile a wide variety of purposes and needs,
often one against each other:
1) It has to allow to write short & quick code;
2) It has to give random numbers very quickly;
3) It has to give high quality random numbers;
4) It has to be used in multi-threaded code.
5) It must be able to perform the most handy and common functions.

I think that can be solved adding 3 RND generators and various helper
functions. Three different random generators can cover most usage cases: a very
fast one, a good one fast enough, and a very good one.
- The very fast one is thread-safe, can be based on R250-521.
- The default one isn't thread-safe and it's designed for most cases. Not being
thread-safe you don't need to create a struct/class to use it, so it allows a
short and handy syntax. It can be Kiss used by Tango.
- The precise one can be thread-safe, a new version of Mersenne Twister is okay.

The helper functions can generate: random integer in closed interval, random
integer in interval open on the right, uniform real value in interval, Gaussian
real value, random choice among given items, in-place shuffling of sequence,
not in-place shuffling, sampling with and without replacement from a given
sequence of items. Many more things are possible, but those cover a lot of
cases.

My d.random module is based on this design, even if few bits aren't finished
yet (the R250-521 isn't integrated yet, there's a fault I have recently found
in the randInt()).

Bye,
bearophile

Don <nospam nospam.com.au> writes:

Andrei Alexandrescu wrote:
 I plan to overhaul a number of modules in Phobos2, such as 
 std.algorithm, std.stdio, and std.random. The changes will render 
 existing code using those modules largely uncompilable. I wonder what a 
 good evolution scheme we should adopt. Walter suggested that I move the 
 old modules in etc/, so changing e.g. std.algorithm to etc.algorithm 
 should make legacy code work.
 
 Is this agreeable? Are there better possibilities?

Since one of the examples given as an aim of the Tango/Phobos merger was 
to allow std.algorithm to work with Tango IO, it would be a shame to 
miss the opportunity to improve compatibility.