openroberta-lab
openroberta-lab copied to clipboard
WeDo source code causes server error when built
Describe the bug
- When you navigate to the source code editor and try to build the source code, a server error is generated.
To Reproduce Steps to reproduce the behavior:
- Create a new WeDo program.
- Go to the source code editor.
- Build the source code.
- See error.
Expected behavior
- The user should not receive a server error.
Screenshots

Device information
- Type: Desktop
- OS: MacOS
- Browser: Chrome
Through testing, I have found that the error that is generated is caused in the "ProjectWorkflowRestController" in the "compileNative" class or more specifically, on line 291 "ProjectService.executeWorkflow("compilenative", httpSessionState.getRobotFactory(), project);."
This causes an error due to the fact that fewer workflows are actually available within the WeDo compiler/program... as shown below:
Normal Available Workflows (This one is specifically for Calliope but is the same for all other robots other than WeDo):
WeDo Available Workflows:
Since there is no "compilenative" workflow in WeDo, the program then throws an error stating that the "Workflow compilenative is null for robot WeDo, check the properties."
@RohanCheri That seems right, I get the same error when I access it on local. Any thoughts on the optimal way to fix this?
I’m not entirely sure where the project workflows themselves are created but I believe that this may be due to the fact that WeDo uses the programs compiler itself since it is written in JSON meaning that it doesn’t have an auxiliary compiler like the other robots do since they are written in a different language that must be compiled into JSON.
@Caffetaria The workflows themselves are stored within the "wedo.properties" in the resources file of the RobotWeDo folder. In order to add one, you just have to go to the bottom of that file and add in "robot.plugin.workflow.runnative and robot.plugin.workflow.rcompilenative."
Following that, we need to give worker actions to these workflows. Looking at other robots, it seems that they either have the actions setup,save,transfer with runnative and setup,save with compilenative or setup,compile,transer with runnative and compile,save with compilenative.
The first configuration, using CompilerSetupWorker as setup, SaveWorker as save, and TransferWorker as transfer, allows for the build to complete BUT since there is no compiler checker, any code that is put in will compile (It will not give any errors even if the code is completely wrong).
Video:
Now, using the second configuration would involve using a CompilerWorker for "compile", such as EV3LejosCompilerWorker, that compiles the JSON code and checks it for any errors. This would eliminate the problem shown above as it would actually compile the files and make sure that there are no errors in the code. The only problem is that this file has not been created yet as there is no WeDoCompilerWorker, so we could also work on making that file (@boonto This would also warrant calling the cross compiler such as in FestobionicCompilerWorker if the cross compiler is compatible with WeDo). One idea that I had to make this was to just call the WeDoStackMachineVisitor as it also reads the JSON and that is what the code for WeDo is in so it could also be used to compile the program and check for errors.
Nice investigations :) The server error should be fixed by adding the specific workflow.
As the language we use for WeDo is our own JSON language based on interpretation there is no compilation needed (it is the same as the simulation language). We have some integration tests (in the server project) which run the "simulation" with some test files and validate whether they work correctly. This could be a way to check the WeDo programs.
However, WeDo can only be used via tablets/phones and is intended for very small children. That's why I think the source code editor won't be the main focus of the users. It should work (not produce errors) though.
Oh okay so we could just run some JSON implementation tests and if they work, then the program is valid?
We only have it in tests right now, you can take a look at the StackMachineJsonRunner
class for more detail.
Oh okay that helps a lot! I just have one quick clarification, in order to run the compiler (the run program in StackMachineJsonRunner) the program takes in 3 inputs. I believe that the first one, programName, would be project.getProgramName(), the second one, programTextInclResultSpec, would be project.getAnnotatedProgramAsXML(), and the last one, stackmachineCode, would be project.getSourceCode().toString(). (As shown below)
Run Function Header:
Proposed Calling Code:
(Ignore the error that comes from not handling the Exception)
Would these proposed parameters be correct?
I believe so, you can cross check with the call in CompilerWorkflowRobotSpecificIT::compileNepo
.
Overtime the error message has changed. Following is the message:
A solution would be to provide a "pretty print" for the stack machine code