Contribution - Stub generator input error

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:

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 :slight_smile:

Thanks for your help :slightly_smiling_face:

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.

1 Like

I will try what you said and tell you what happen.

It fix most of the errors, but there are still some language that it doesn’t work in:

But you help me a lot :grinning:

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?


I don’t think you can do anything… The stub is now correct…
Perhaps the CG team can do something @TwoSteps ?

1 Like

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.

Did you change something ? I always have the same errors…

So it fixed or not? I think I change something because it is working for me but maybe it just for me that why ask you.

It’s not. And I don’t see any change in the stub code.

OK, thanks. So we can just wait for someone from CG to help us :disappointed_relieved:

We’ll look into it as soon as we can.

Thanks a lot @_CG_Thibaud . I appreciate this.
Hope you will fix it fast :grinning:

I have had an issue with OCaml related to stub generator returning:
“Exception End_of_file”

This was also discussed here:

I played around a bit and found that the common issue with my contribution and the above puzzle was a multi-command loop line, like so:

loop N read name:word(10) R:int

After changing that line of the stub generator to a single command, like so:

loop N read resistor:string(20)

And then the generator code for OCaml execute with no exception and printed a sample print string.



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. *)
     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;
    10	let circuit = input_line stdin in
    12	(* Write an answer using print_endline *)
    13	(* To debug: prerr_endline "Debug message"; *)
    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).


the OCaml issue has been fixed. Thanks for reporting it and explaining it.