Enhancement: Access to command line parameters

[reks99]

Hi,

I would ask, if it is possible to get access to the comandline arguments i.e. argv and argc. It can be a checkbox in the Export options.

The executer can ask for the arguments, when the flag is set before start execution.

Fine regards Rolf

[codemanyak]

@reks99 First of all: What command line arguments are you interested in? The ones used to start Structorizer? Being in most cases empty and sometimes an .nsd, .arr, or .arrz file name... Wouldn't make much sense, would it? Or do you think of a possibility to fake command line arguments for the debugging like in IDEs? This would seem superfluous because if you write a subroutine diagram with arguments argc and argv (like in C) or just argv (like in Java where you may derive the length from an array) then Executor will ask the user for values for these arguments on start. So I'm a little puzzled what exactly you request.

[codemanyak]

@reks99 Addendum:

It can be a checkbox in the Export options. The executer can ask for the arguments, when the flag is set before start execution.

What have the export options to do with Executor? If you write a subroutine diagram int main(argc, argv) then it will be exported to C as main program with access to the command line arguments and you can test it in Executor without additional gimmicks. Just enter the number of arguments for argc and an array initializer like e.g. {"param1", "param2", "param3"} for argument argv. If you export to bash, however, then of course the generator would assign argc=$1 and argv=$2, which is not exactly what you want because argc and argv aren't recognized as specific command line arguments but handled like ordinary parameters. But you may easily adapt it in the produced code to argc=$# and argv=$@ to restore the original meaning. I think this shouldn't be unreasonable.

[reks99]

Hi Kay,

I would like to design programs in structurizer which can have commandline arguments. Until now the export to the C language has "main(void)" exported. My whish is the possibility to have "main (char *argv[], int argc)" exported - or similar in other languages.

This may require that structurizer has these two argument variables somehow as (fixed) internal variables, so a loop like "until all arguments are read do" can be constructed.

The executer can't work with such a loop until it gets the wanted argument.

Fine regards Rolf

[codemanyak]

Again. Try this: or this:

The diagram is not forced to use argc or argv but you can provide it. If you don't want to provide arguments then you just enter 0 and {}, respectively, on start. Where is the problem? Have a look at the exported C code. The one for the second diagram is already perfect. The result for the first one requires that you set in "argc" where the TODO comment asks you to fill in a value instead of the "???" dummy:

(By the way, main (char *argv[], int argc) is the wrong order of arguments.) I still don't get what you want. Of course the export could always place the two arguments in the main function. But what for, while the diagram doesn't make use of them? And if you want to you'll have to declare them anyway, see above.

[reks99]

Hi,

I think there is a misunderstanding. My idea was to add a feature/method to access the command line parameters in a language-independent way from inside structurizer. Then when exported one can study the differences between the programing languages because structurizer can also help to lern how the program will look in differnt languages.

Fine regards Rolf

[codemanyak]

Ah, sorry, now I understand. You propose a kind of built-in function that provides the array of command-line arguments (or alternatively, two such functions, one returning the number of arguments, the other the i-th argument), which should then be translated into the different language-specific mechanisms to fetch them. Well, but it will just make little sense to use them in the Executor environment because you could only configure some faked arguments (in well-established IDEs like Eclipse, VisualStudio etc. there are such settings where you may put in constant "command line arguments" for testing purposes). This would of course be possible and might possibly even help importing source code (there had already been requests from the COBOL front), but umh... What would come next? Retrieval of environment variables, I guess...

[reks99]

Hi,

What would come next? Retrieval of environment variables, I guess...

This is always a very language specific task and normaly not easy to program. So I think that there is no need to implement this in structurizer.

Fine regards Rolf

[GitMensch]

This is always a very language specific task and normaly not easy to program. So I think that there is no need to implement this in structurizer.

It is identical language specific as command line arguments... If Kay is up to add builtin functions for a lot of language specific tasks this is fine, but it would be even more useful if he added a clear documentation how to do so, enabling others (lets say you for the command line arguments and me for the environment) to actually provide what we may request in the future.

[codemanyak]

it would be even more useful if he added a clear documentation how to do so

That's certainly the right thing to do. In order to be able to do so I will need some time for another redesign of the generators. Because of the really very language-specific problems I had to solve in the last two years the structure has grown pretty wild and is far from the originally intended modular design. So I will first advance my plans of a consistent syntax tree representation of all expressions such that built-in functions and procedures as well as operators can unambiguously be identified. Then we'll have a chance to regain some overview. Remember that every built-in function and API has to be translated into 13-14 different languages. And while I can only work with regular expressions on plain text or with already more secure approaches over tokenized lists but have to convert them to and fro it's all patchwork. And every enhancement makes it worse. So if you all agree I would rather concentrate on a clean and consistent syntax analysis, also in order to improve the performance. Parts of it are ready but need more elaboration. And it must be tested with regard to memory and time complexity. I want to avoid the repeated tokenizations and concatenations and the frantic search for a point where certain matching and replacements should ideally take place without spoiling all what had been transformed before or will have to be transformed thereafter. If in the event there will be a central point in all generators where built-in functions are to be handled then this will be a big achievement allowing the requested clear documentation. (At least for a while...)

[reks99]

Hi Kay,

if you will allow to enhance structorizer in the future, it is quite a good thing to reorganize the code. All my comments in the last days have all been suggestions (except the start script tip). I will continue use structurizer and send errors.

Fine regards and "see you later" Rolf