Hi. I created a contribution, an easy puzzle, and some user brought to my notice that in some languages when you open the game in IDE and run the program without changing something in the code you get errors. I believe that the problem is that the stub generator input translate the code to those languages with errors. Do you know what is the problem and what should I do to fix it?
The list of the languages that have errors on are:
F#
Go
Groovy
Java
Kotlin
Objective-C
Pascal
Scala VB.NET
A link to my contribution so you can check it yourself:
This is what the user said:
The code stub generator throws exceptions in several languages : F#, Go, Groovy, Java, Kotlin, Objective-C, Pascal, Scala and VB.Net.
For F# it looks like a bug on CG side, the generator doesn’t detect that a previously declared variable is in another inaccessible scope and should be redeclared. I haven’t looked at the other ones, hopefully you can figure it out or find some help on the forum
I think you want to use word rather than string in the second loop - a string can contain spaces so in many languages it reads a whole line (so multiple strings per line separated by spaces doesn’t work). A word cannot contain spaces so it should read the space separated characters correctly.
Naming variables integer and character is also going to cause problems in languages where these are reserved words.
The go errors appear to be a bug in the stub generator (declares a variable in the first loop and tries to use it in the second one), though maybe it’ll be fixed if you don’t read strings in the second loop.
A good parts of the errors are caused by the use of ‘string’ instead of ‘word’, and the variable named ‘integer’. But there’s some problems from the stub generator.
I will list them here per language:
F#: Variable ‘words’ declared in a for loop and used without declaration in another for loop, out of the scope of the first declaration.
Scala: Same problem with ‘inputs’.
Go: Same problem, ‘inputs’ declared in the first for loop and used with ‘=’ instead of ‘:=’ in the second. And second problem ‘character’ declared but not used in the second for loop, while the problem is handled in the first loop by the use of ‘_’.
I fixed the problem with ‘word’ instead of string and ‘num’ instead of integer and ‘C’ instead of character. How can I fix the problems you mention? Should I just wait for someone from CG to fix them?
Can you check now if the problems with F# and Scala fixed?
Because I think they are.
If they are fixed the only problem left is in Go because C is not used.
As the puzzle creator, you should only care about writing a proper stub description based on the provided stub semantics. You should not really care about the result: That’s CG’s part of the job. If there are bugs in the generated code in some languages because the generator not does follow its own semantics, well, I’m afraid the only thing you can do is ask CG to fix.
It’s not actually an improvement to remove some parts of the parsing in order to avoid that kind of errors.
About your contribution, here is the incorrect generated OCaml code:
1 (* Auto-generated code below aims at helping you parse *)
2 (* the standard input according to the problem statement. *)
3
4 let n = int_of_string (input_line stdin) in
5 for i = 0 to n - 1 do
6 let name, r = Scanf.scanf " %s %d" (fun name r -> (name, r)) in
7 ();
8 done;
9
10 let circuit = input_line stdin in
11
12 (* Write an answer using print_endline *)
13 (* To debug: prerr_endline "Debug message"; *)
14
15 print_endline "Equivalent Resistance";
And here is for instance what should be generated (to avoid improperly mixing scanf, which does not read the whole line, with input_line):
6 let name, r = Scanf.sscanf (input_line stdin) " %s %d" (fun name r -> (name, r)) in
This does not seem very hard to fix for CG (invoking @TwoSteps).
