Embed variables inside source code

[angelorpa]

Compiling code stored in text files whose names have more than 10 characters long produce some commands to fail, like the CRTBNDRPG command, so to avoid it, the extension could prompts for an object name that complies with the IBM i objects naming rules

CRTBNDRPG failed becuse source file name lenth is grater than 10 chars:

Posible Solution:

[worksofliam]

Wow, a really cool idea. I want to extend this and maybe suggest storing the name into .vscode/objects.json so the user doesn't have to keep reentering the name.

@edmundreinhardt Check this out. What do you think?

[edmundreinhardt]

Bob's current provision for this, is to have 'objname_Any arbitrary text.rpgle'. The advantage of this approach is that there is not magical side file or prompt required and that it is pretty obvious what the object name is.

[worksofliam]

@edmundreinhardt Sadly I don't think this is a standard we are going to implement into the base (after discussion with many people, it's not a favourable approach to include the object text in the source).

[worksofliam]

@angelorpa I will look into getting this text box added, but more importantly looking for a way to store this information also.

Would you prefer we store it as part of the folder (inside .vscode/ dir perhaps?) or as part of VS Code internal storage?

[angelorpa]

@worksofliam I thinkg the extension should not be dependent on a compiling tool. The extension offers a series of defaults actions when working with members, I think this should be applied for stream files too, actually it doesn’t, but that cold be another feature 😊 the idea is the extension help the user to avoid a compilation failed when executing actions that not imply third-party compilation tools like gnu make or bob, I think this improve the UX.

Actually the extension assign the object name using the entire stream source file name or the result of split it at the first position where a hyphen ‘-‘ is founded, not a underscore.

https://github.com/halcyon-tech/vscode-ibmi/blob/c99fda926c91d90d0ffea1adc7eb96ef1b4163b9/src/api/CompileTools.ts#L317-L320

I think the rule should be the first 10 characters, but presented as a suggestion to the user and let he/she decide the final object name.

I agree with @worksofliam, the extension should store the user response so no need to ask over and over for the same, to do this I prefer using a json file in .vscode so the user has the option to change it, if the property is empty the extension will ask again other wise use the property value but always checking his len. May be this file could maintain the objects dependencies and could be a base for a standard to communicate the objects dependencies to wherever third-party compiling tool or in meaning time it could be used by another future to create a make or Rules.mk files

[edmundreinhardt]

If you insist on a side file, it should NOT be a hidden .vscode filen that is likely to be .gitignored, this is something that should be stored in git with the source as it is critical information to be able to build it. putting it in .ibmi.json is consistent with the iproj standard https://ibm.github.io/ibmi-bob/#/prepare-the-project/ibmi-json

• the goal is to make the iproj a standard that benefits the whole platform and not a proprietary format

I am happy to put the iproj standard in any repository or location as it is not BOB specific and should not be implied to be such

It is possible to store your own tool specific information here I was trying to avoid stream file specific information here as it would require maintenance if a file/folder is renamed. the advantage of having it in .ibmi.json is that it is in the local folder and therefore is not affected by folder renames

[edmundreinhardt]

Actually the extension assign the object name using the entire stream source file name or the result of split it at the first position where a hyphen ‘-‘ is founded, not a underscore.

https://github.com/halcyon-tech/vscode-ibmi/blob/c99fda926c91d90d0ffea1adc7eb96ef1b4163b9/src/api/CompileTools.ts#L317-L320

I think the rule should be the first 10 characters, but presented as a suggestion to the user and let he/she decide the final object name.

You are quite right that it is the separator should be '-' and not '_' so that it can be distinguished from the object name itself

[edmundreinhardt]

Not that Code for i will have to deal with the other issues that .ibmi.json solves, such as the target EBCDIC CCSID for compiles.

[angelorpa]

If you insist on a side file, it should NOT be a hidden .vscode filen that is likely to be .gitignored, this is something that should be stored in git with the source as it is critical information to be able to build it. putting it in .ibmi.json is consistent with the iproj standard https://ibm.github.io/ibmi-bob/#/prepare-the-project/ibmi-json

• the goal is to make the iproj a standard that benefits the whole platform and not a proprietary format

I am happy to put the iproj standard in any repository or location as it is not BOB specific and should not be implied to be such

It is possible to store your own tool specific information here I was trying to avoid stream file specific information here as it would require maintenance if a file/folder is renamed. the advantage of having it in .ibmi.json is that it is in the local folder and therefore is not affected by folder renames

that's great, in fact I was tempted to ask to the possibility to use the iproj.json file for this kind of storage because in fact if any file or directory of the project structure are renamed or deleted so regardless the file which contains the relation : file source name and object name, it should be update, I think this could be done by the extension, it could monitor for this type of events

[edmundreinhardt]

So we should default to the minimum of first 10 chars, or up to '-' in file name. If the user is not happy with that they can override. It is a question whether this should happen EVERY time, or the default should happen and a context menu and/or action could prompt for a target object name. I lean towards that latter, so that a compile is not so chatty and that the recompile is optimized. I suppose we could have a notification message if there is a concern with discoverability.

[worksofliam]

@angelorpa I am going to put together a little to do list for this feature this week since there are a bunch of things I want to go along with this.

Thanks for this great idea!

[worksofliam]

Just a side note: I am also thinking the file could contain object text, and perhaps other custom variables.

[worksofliam]

Perhaps we could integrate this meta data into the file? This will update/overwrite variables before the Action is run.

RPGLE:

     ///
     // &name: ABCDEF
     // &text: This is thetext
     ///

CL:

/*
  &name: OBJECT
  &text: Hello world
*/

COBOL

      * &name: COBOL
      * &text: My cobol program

^[\s\/\*#\.]*\&([\w]+):(.+)

Test cases:

 g   // &name: ABCDEF
  g  // &text: This is thetext

/*
g &name: OBJECT
  &text: Hello world
*/

     * &name: COBOL
  d   * &text: My cobol program

.* &name: hello world

# &name: hello world

[edmundreinhardt]

Here is the regex to find all the variables

(?:(?:^.{4}[AHDCIO ]\*\s*)|(?:^.{6}\*\s*)|(?:^[\s\/\*#\.]*))\&([\w]+):(.+)