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:
[dependencies]
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));
}
yes, weâll enable back SmallRng. About rand_core, Iâll propose it! Thanks for the clear explanation
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. 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 )
@TwoSteps
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.
error_log((integer)ini_get(âdisplay_errorsâ));
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âŚ)
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('display_errors'));
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("coucou");
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 :
stderr
32767
coucou
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.
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)
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
Thanks, hopefully we will have it.
PS: you wanted to say âlast yearâ instead of ânext yearâ as it make no sense otherwise.
@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.