>> https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
>> [1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694

Regarding Task names that start with a number, like rosettacode_24_game_solve_00.d, I usually prefix them with "rc_".

Bye,
bearophile

>> [0] https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
>> [1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694

Another reason for some of your entries to not compile seems to be that you have missed that some entries need other entries to compile, so "rc_24_game_solve.d" needs "permutations2.d" and "arithmetic_rational.d", and then compiles and runs fine. (I number 1 2 3 ... the tasks that have more than one D solution).

Bye,
bearophile

On 1/15/14 4:18 PM, bearophile wrote:

> What version of the D compiler are you using? I am assuming Rosettacode to be compilable with the
> latest "bleeding edge" compiler. So if you use the latest released compiler some of the entries will
> not compile. Such entries should not be "fixed" at all.

I think this is a mistake.  They should compile with a released compiler.  They also likely form a potentially interesting set of regression tests that someone ought to volunteer to test beta's against.

Brad Roberts:

> I think this is a mistake.  They should compile with a released compiler.

Why? And why do you think that outweighs the several advantages of having entries compilable only with the latest beta compiler?
(Currently there are 40-50 entries that don't compile with the released dmd 2.064.)


> They also likely form a potentially interesting set of regression tests that someone ought to volunteer to test beta's against.

Rosettacode site has many different purposes; I also use those programs to test the dmd compiler for regressions. But to do this effectively you have to use the latest compiler changes.

Also, how can you update manually on the site tens of entries all at once when a new compiler comes out?

Bye,
bearophile

On 1/15/14 4:42 PM, bearophile wrote:
> Brad Roberts:
>
>> I think this is a mistake.  They should compile with a released compiler.
>
> Why? And why do you think that outweighs the several advantages of having entries compilable only
> with the latest beta compiler?
> (Currently there are 40-50 entries that don't compile with the released dmd 2.064.)

Requiring that users of the code in resottacode be using bleeding edge, unreleased, compilers is a disservice to those users.  Typical users will not and should not need to use anything other than a released compiler.

>> They also likely form a potentially interesting set of regression tests that someone ought to
>> volunteer to test beta's against.
>
> Rosettacode site has many different purposes; I also use those programs to test the dmd compiler for
> regressions. But to do this effectively you have to use the latest compiler changes.
>
> Also, how can you update manually on the site tens of entries all at once when a new compiler comes
> out?

The point is you shouldn't have to, unless the code is taking advantage of broken behavior.  Any changes that 'have' to be made due to a compiler release need to be carefully examined as probable regressions in the compiler.

Brad Roberts:

> Requiring that users of the code in resottacode be using bleeding edge, unreleased, compilers is a disservice to those users.  Typical users will not and should not need to use anything other than a released compiler.

Some of the rosettacode usages/purposes are:
- Trying new compiler features to see if they work correctly;
- Try the new compiler features to learn to use them effectively;
- To test the compiler betas to see if they have "regressions" if you try to use the new features.
- To show "good" (== short, fast, elegant, clean) D code, thanks to some nicer recently introduced compiler improvements;

So do you want to throw away those purposes?
Also keep in mind that if you throw away those purposes, I will lose some of my desire to work on Rosettacode, so you will have a less good and less updated rosettacode site. And I have found probably more than 300 dmd bugs/regressions thanks to those beta-related purposes. If you throw away those purposes you will lose a significant amount of my future bug reports. Are those prices low enough for you?


> The point is you shouldn't have to, unless the code is taking advantage of broken behavior.  Any changes that 'have' to be made due to a compiler release need to be carefully examined as probable regressions in the compiler.

One of the points of improving a compiler is offering new features that are advantageous to use. If you don't want to use them it often means they are a failure. In many other cases the dmd compiler rejects older code that was wrong, because it becomes more tight.

Rosettacode tasks are usually short. If you don't try new compiler features in such little programs that have no production-level significance, then you will never try them in production code, and you will probably use just C-like code.

Being a little compiler-bold in those tasks is acceptable.

Bye,
bearophile

qznc:

> [0] https://bitbucket.org/qznc/rosetta/src/da12e3673b0d/compile_all/?at=master
> [1] https://gist.github.com/qznc/9ba4b0e78abfc35d4694

Few of the tasks of your list were never updated to D2/Phobos, and they should be updated.

Among the ones that are updated, I have found five that don't compile on dmd 2.065 because of compiler changes and one (I think already reported) regression in std.array.array:

arithmetic_evaluation.d
balanced_ternary.d
combinations_with_repetitions1.d
k_means_plus_plus_clustering.d
names_to_numbers.d or number_names.d

I will try to fix them (and probably I will leave the one with a regression untouched).

Bye,
bearophile

> arithmetic_evaluation.d
> balanced_ternary.d
> combinations_with_repetitions1.d
> k_means_plus_plus_clustering.d
> names_to_numbers.d or number_names.d

I have "fixed" them.

This is the problem in array, already in Bugzilla, I think it's a kind of regression:


import std.array: array;
immutable foo = [""].array;
void main() {}


The problem with inout in balanced_ternary.d was caused by inout semantics that keeps subtly changing every month. I don't know the causes of such micro-regressions.

Bye,
bearophile

On Thursday, 16 January 2014 at 01:11:23 UTC, bearophile wrote:
> - To test the compiler betas to see if they have "regressions" if you try to use the new features.

This sounds somewhat paradox to me. How can a new feature have a regression? A "regression" means it has worked before, but new feature did not exist before.

Maybe the question is about "before"? In my understanding "before" is "latest release", whereas "current" is "beta release" or "git HEAD". Do you mean "before" as something like "commit deadbeef~4" whereas "current" is "commit deadbeef"?

I see nothing wrong with using code from Rosettacode to try out new features. It is weird though, if people want to test an example, you have to tell them to compile dmd from git.

In practice the difference between the uses is not that important I think, because the sheer number of code snippets and release frequency means that most examples can be compiled with the latest release no matter what bearophile does. ;)

Btw are your scripts public, bearophile?

qznc:

> This sounds somewhat paradox to me. How can a new feature have a regression? A "regression" means it has worked before, but new feature did not exist before.

"Regressions" on older betas; or to see if using the new features breaks other apparently unrelated parts of old code.


> In practice the difference between the uses is not that important I think, because the sheer number of code snippets and release frequency means that most examples can be compiled with the latest release no matter what bearophile does. ;)

Right. The percentage of future compilable entries is small, usually much less than 5%. And this was even more true in past, when the frequency of D releases was higher.


> Btw are your scripts public, bearophile?

They are the common kind of little scripts that you prefer to rewrite on your own.

Bye,
bearophile