[Dltk-dev] Re: Extending and increasing visibility for members of Abstr

[Gabriel Petrovay <gabriel.petrovay@xxxxxxxxxx>]

Hi Alex,

Now the question and suggestion:

> 1. Allowing the automatic completion of (arguments/environment
> variables/name) based on the logic defined in the interpreter install
> type


I have added setInterpreterName(String) method you suggested earlier.
Please let us know if you need additional methods here.

****** What is the branch you are working on because I am trying to see your updates in the CVS Browser and I cannot find them. You are certainly not working on the HEAD version.

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.dltk/core/plugins/org.eclipse.dltk.debug.ui/src/org/eclipse/dltk/internal/debug/ui/interpreters/AddScriptInterpreterDialog.java?view=log&root=Technology_Project&pathrev=HEAD

****** Take this example: I have an interpreter that I search for. I find interpreter.exe and I click OK in the file Browse window. The path to the executable appears in the interpreter executable path field. Also the name is generated (here comes the method you say you just added). I want also to generate the Interpreter Arguments because my interpreter has a more complicated command line format. In order for the user not to be forces to go to the documentation page of the interpreter and then write the arguments by hand, I could do this for him directly. For this a method called AbstractInterpreterInstallType.generateInterpreterArguments() is needed. This method will be called somewhere inside this call hierarchy :

        fInterpreterPath.setDialogFieldListener(new IDialogFieldListener() {
            public void dialogFieldChanged(DialogField field) {
                setInterpreterLocationStatus(validateInterpreterLocation());

                updateStatusLine();
            }
        });

The same applies for interpretes that need certain evnironment variables set. (on Unix-based system, the LD_LIBRARY_PATH is needed) I can avoid the user editing these variables and I can put them there if a method AbstractInterpreterInstallType.generateInterpreterEnvironmentVariables() is provided.


> 2. The Interpreter install type should also have one method [boolean
> supportsEnvironmentVariables() ] in order to allow the enabling of
> environment variable block per install type. (This cannot be

> performed
> in the extended MyAbstractScriptInterpreterDialog class because this
> should not be aware of the install types)

Could you please give the detailed description why this method would be helpful?


****** Not all interpreter types need an environment block to be shown. (DLTK right now doesn't even show this Variable block). Different IInterpreterInstallType's know if they needEnvironmentVariables(). Such a method allows the AddScriptInterpreterDialog to display the EnvironmentVariablesBlock only if the install type needs it.



> 3. As suggested in a previous email, the generation of the
> interpreter
> names should be overridable by the user in the
> InterpreterInstallType.
> The default implementation (suffixing with "(1)", "(2)",... ) should

> already be the default implementation of such generating method. In
> this way I could read a version number from somewhere and compose the
> name with the version in it, like JDT does it.

I made some refactoring in AddScriptInterpreterDialog:

- changed visibility of validateInterpreterLocation
- extracted generateInterpreterName & validateGeneratedName


***** There is certainly a problem with seeing those changes you made. Do you work on certain brunch?


> 4a. Also the interpreter arguments should be parametrized with
> variables. (DLTK should add some additional variables like:
> input_script_file, launch_config_args, etc). This is because not all

> the interpreters accept the format of the call:
>   script.exe [args] script.file
> others might need to put arguments after the script file, a.s.o.
> 4b. This is a more generic alternative to 4a. The Arguments field

> should be changed to Script Command Format. And allowing the full
> customization of the interpreter command line. An additional variable
> for this would be: interpreter_install_location.

The most generic way is to override org.eclipse.dltk.launching.AbstractInterpreterRunner.renderCommandLine(InterpreterConfig) method.


***** 4a. Even a reimplementation of renderCommandLine() could benefit from variables in the Interpreter Argument field. How do you solve the following problem (in an elegant way)? You have an interpreter that has the following command line format:

interpreter.exe -argO1 -argsM1 input_script_file -argM2 -argO2 argO2value

where -argsM1 and -argM2 are mandatory and -argO1 and -argO2 are optional. argO2value is the value of -argO2.

The AbstractInterpreterRunner.renderCommandLine could easyly do the job if variables (like input_script_file, install_location) are set in the Argument field of an InterpreterInstall.

***** 4b. You are right, the most generic logic can be performed in the suggested method


Hope this helps!


Regards,
Gabriel

-- 
MSc Gabriel Petrovay
MCSA, MCDBA, MCAD
Mobile: +41(0)787978034