Closed IrisLuc closed 7 years ago
About what export are you talking please? Pascal?
OK, got your mail too. (Affirmative Pascal)
@codemanyak : I think the problem is in Generator.transformInput()
which does not consider that the "input" and "output" identifiers could be followed by nothing too.
The same problem exists with the "Write" instruction, which should convert to a "writeln()" ....
Could you please try the new version and give me some feedback?
Thank you. It's working fine now.
2015-12-10 14:15 GMT+01:00 Bob Fisch notifications@github.com:
Could you please try the new version and give me some feedback?
— Reply to this email directly or view it on GitHub https://github.com/fesch/Structorizer.Desktop/issues/51#issuecomment-163611174 .
Indeed I did not at all consider input or output lines without further content. If I did, then I regarded them as useless and rather syntactical mistakes. (I still don't see what a readln()
instruction without a variable might be good for - buffer cleaning? How should the Executor react to it? And are we really concerning about output formatting here, while the Executor pops up a message box on every output instruction? I understood very well that it's about code export but shouldn't behaviour on execution and generated code somehow be related?)
@fesch : By the way: Would it make sense to allow comma-separated lists of input variables in an input instruction and comma-separated lists of expressions after an output keyword?
The latter might me easier to export into different languages than to convert Java concatenation operators ('+') into what might be needed by another programming language to write several objects into a single line. Actually, this is closely related to issue #54.
readln() instruction without a variable = pause & wait until enter pressed
No, I don't think code generation and execution must be related. As far as I know, there are people out there that use the executor without generating code and vice-versa. I know, everybody has special needs, but doesn't putting them into relation complicate things? Execution as well as export to code is (and will always remain!) an interpretation of a drawing. I think we should not forget what purpose the NS-diagrams have been designed for: structuring things without the need of code.
In Pascal, comma separated lists of variables in an input work (if I remember well), but I never used them and never accepted them from my students as I always wanted them do do some meaningful output before. So I don't see the need to have that.
Fir the output, well, that's something else. In Pascal this was possible and even needed, as there was no automatic conversion of e.g. integers into strings when concatenated. So here I think that it would make sense to use comma separated lists ....
This fix causes nonsense in other target languages and needs further fixing in the remaining code generators.
Tasks to accomplish:
Shell script export done now as well, Perl and Python revised
Yes, export to pascal Op 10 dec. 2015 13:46 schreef "Bob Fisch" notifications@github.com:
About what export are you talking please? Pascal?
— Reply to this email directly or view it on GitHub https://github.com/fesch/Structorizer.Desktop/issues/51#issuecomment-163600253 .
Export of an empty input instruction to C# produces code line = Console.Readline();
.
Export of an empty output instruction to Python produces code line print(, sep='')
.
Fixed with 3059e6f.
I’m having some difficulties with the latest version of Structorizer. The read-instruction is not converted if it isn’t followed by the name of a variable.
Correct conversion:
Read getal
→readln(getal);
Incorrect conversion:
Read
→Read;
This seems to be a new issue. It was working fine previously.