Languages update

No worries, thanks for the (both) updates!

Thanks for the clarification. The reason the update broke @tarriel’s code is that rand 0.6 used to contain SmallRng by default, while in 0.7 it’s an optional feature. It would make a lot of sense to enable it though, since it’s small and fast, so a good choice for writing bots on CG. It would also avoid breaking bots that used it.

It would also be nice to depend on rand_core. That won’t add any overhead since it’s already an indirect dependency, but it would make it visible to bots, and therefore easier to define custom RNGs.

In summary, I’d propose to use this dependy declaration in Cargo.toml:

rand_core = "0.5.1"
rand = { version = "0.7.2", features = ["small_rng"] }

Test program:

use rand::{Rng, rngs::SmallRng, SeedableRng};
fn main() {
    let mut rng = SmallRng::from_entropy();
    println!("{}", rng.gen_range(0, 100));
1 Like

yes, we’ll enable back SmallRng. About rand_core, I’ll propose it! Thanks for the clear explanation :slight_smile:


Since the latest language update, in case of a syntax error in my code in PHP, there is no error message on the console at all, the solo puzzle solution simply timeouts without providing the answer.
Previously the PHP interpreter showed some meaningful error message.
I am not too familiar with this aspect of PHP but it might be some php.ini setting issue, or the default behaviour changed. Could you please check? It degraded coding productivity greatly. :frowning: Thanks in advance.


PHP 7.4 will be GA this month so it missed the recent language update. I suggest to include it in the next round as it comes with some nice new language features, such as typed class properties (coders of strongly typed languages: pls don’t laugh :slight_smile: )

My guess for the culprit of the PHP lack of error message problem:
Maybe ‘display_errors’ is set to off in php.ini, because adding this line to any of my code shows 0.


Unfortunately it seems I am not authorized to modify this from the code, following line still results 0

ini_set(‘display_errors’, 1);

The ‘error_reporting’ directive seems to be set to E_ALL or something similar (32767) which is fine, but errors are still suppressed.

Please help, without any syntax error messages coding is like flying blind! (Just solved the latest easy puzzle ‘graffity’ and it was real pain…)

1 Like

Yes this lack of PHP errors is weird. For information, we use the flag -d display_errors=stderr when executing php.
We’ll investigate ASAP.


The display_error is effectively set to stderr and the error_reporting to E_ALL.
Apparently, the setting does not work in two way at the moment, but maybe I just do it in a bad way, I don’t know

ini_set('display_errors', 'stdout'); //does not work, but we do not need to change it anyway
error_log(ini_get('error_reporting')); //equal to E_ALL can be change by 'error_reporting(E_WARNING)' but still does not show anything

error_log(var_export([1, 2, 3], true));

echo $toto; //should provide a warning 
echo $toto[3]; //should provide a warning 

aze(1); // should provide a Fatal error 

And the current output of this

Sortie standard :

array (
  0 => 1,
  1 => 2,
  2 => 3,

Which should not be in the standard output (commenting the ini_set('display_errors', 'stdout'); provide the exact same output) . But weirdly even if the IDE show them as standard output, the backend just ignore them, as they are considered as standard error. Also the script stop at the call of aze() a not existing function without any message. In multi it just provide a TO.

1 Like

PHP error output fixed. Unknown mistake was made when installing. Re-installing fixed it.

(BTW, you cannot do ini_set because we add -d disable_functions=ini_set when executing PHP)

1 Like

@dbdr @tarriel we fixed rand for Rust as requested


We also fixed an issue with Console.Error.WriteLine in VB.Net

In the process we changed C# and VB.Net runtimes to correctly point to the lastest .Net 4.7.2 assemblies. Previously it was a mix of 4.5 and 4.7.2 assemblies causing somme issues, at least in VB. I hope we did not break something else.


Thank you for the quick help!

Thanks @_CG_XorMode, SmallRng is available in Rust now.

By the way, I remember CG started to keep compiled versions of bots instead of recompiling before each game. Are the compiled versions only kept for a limited amount of time?

Different compile modes for Rust makes it impossible to reproduce some games in IDE (due to timeouts).

Of course this is better than debug everywhere, but it would be nice to have release mode in IDE. Or increased timeouts.


@TwoSteps: Do you still plan to move to .Net Core 3.1 for the next context?

While it’s nice to see a language update on C#, but it’s still only Mono 4.6…
The improvements in .Net Core 3.1 are huge in term or performance, productivity, etc…
It’s not really appealing for me as a C# dev, to come and have fun with a very old version.

I understand that it’s hard and long to update languages on CG but at least for C# (who is widely used in the market) I wish we were a bit closer to the latest version.

It’s a bit difficult to bring new people in if the versions are too old.


Yes. We started looking into it again at the end of last year. A big project for CodinGame for Work may have switched the priorities, but I believe we still hope to have it before the next contest. I’ve pinged the devs for some news

1 Like

Thanks, hopefully we will have it.

PS: you wanted to say “last year” instead of “next year” as it make no sense otherwise. :slight_smile:

1 Like

@TwoSteps: any news on the .netCore update?
CG is still on C# 7.0 (Mono 6.4.0, .NET 4.7). Compiled with ‑unsafe

I’ve rework my Ghost In The Cell bot, with .NetFramework 4.7 on windows and it’s not compiling on the server because of locale fonction…

It’s really a pain these differences between the two version (putting aside the fact we don;t have the new features also)…

As the contest has been push back, you should have a bit of time to do the upgrade, no?

yes, we still want to move from Mono to .NET before next contest


Famous last words.