Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change script schema #81

Closed
gilesknap opened this issue Jul 3, 2023 · 14 comments
Closed

Change script schema #81

gilesknap opened this issue Jul 3, 2023 · 14 comments
Milestone

Comments

@gilesknap
Copy link
Member

Another schema change proposal:

At present we have:

script:
  - type: once
    value: |
      some once only script lines
  - type: function
    name: myFunc
    args:
      ArgOne: "{{ ARGONE }}"
  - ordinary text
  - appears as a list
  - of lines

post_ioc_init:
  - lines of text
  - after iocInit

Proposed change for discussion:

script:  
  - type: once
    value: |
      some once only script lines
  - type: function
    name: myFunc
    args:
      ArgOne: "{{ ARG_ONE }}"
  - type: text
    value: |
      ordinary text
      appears a single string
  - type: post_ioc_init
    value: | 
      lines of text
      after iocInit

I'm not sold on type: text - looking for better names for this

@gilesknap
Copy link
Member Author

gilesknap commented Jul 3, 2023

That was wrong - should be:

script:  
  - type: function
    once: false
    name: myFunc
    args:
      ArgOne: "{{ ARG_ONE }}"
  - type: script
    once: false
    post_init: false
    value: |
      ordinary text
      appears as a single string

@gilesknap
Copy link
Member Author

Although I don't know of a need for it we could also support post_init in the function type.

@gilesknap
Copy link
Member Author

@coretl waddayathink?

@gilesknap
Copy link
Member Author

After discussion with @coretl and @GDYendell we have:

pre_init:  
  - type: function
    when: first / every / last
    name: myFunc
    args:
      HumanReadableFunctionArgumentName: "{{ ARG_ONE }}"
  - type: comment
    when: first / every / last
    value: |
      ordinary text
      appears as a single string 
      which can be multi-line
      # is automatically added for us in the 
post_init:
  AS ABOVE

@gilesknap
Copy link
Member Author

@GDYendell @coretl

Gary, you may remember that I was reluctant to remove the ability to add fre-form text to the startup script. I'm now implementing the change as above and have come across an example of where I think fre-form would be tidier.

Let me know what you think:

    # TODO: the removal of script and post_ioc_init means we need to
    # explicitly list each of these functions and is rather verbose
    # TODO consider adding a "text" type to pre_init and post_init
    # for this purpose
    pre_init:
      - type: comment
        when: first
        value: |
          One time initialization for all event receivers
      - type: function
        when: first
        name: ErTimeProviderInit
        args:
          priority: "{{ priority }}"
      - type: function
        when: first
        name: installLastResortEventProvider
        args: {}
      - type: function
        when: first
        name: syncSysClock
        args: {}

        # ABOVE USED TO BE LESS VERBOSE
        # script:
        #   value: |
        #     # One time initialization for all event receivers
        #     ErTimeProviderInit {{ priority }}
        #     installLastResortEventProvider
        #     syncSysClock

@gilesknap gilesknap mentioned this issue Jul 6, 2023
@coretl
Copy link
Contributor

coretl commented Jul 6, 2023

How about we merge function and comment and have one thing that does both:

    pre_init:
      - when: first       
        comment: One time initialization for all event receivers
        function: ErTimeProviderInit
        args:
          priority: "{{ priority }}"
      - when: first
        function: installLastResortEventProvider
      - when: first
        function: syncSysClock

@coretl
Copy link
Contributor

coretl commented Jul 6, 2023

Outputs:

# One time initialization for all event receivers
# ErTimeProviderInit priority
ErTimeProviderInit 1
installLastResortEventProvider
syncSysClock

@coretl
Copy link
Contributor

coretl commented Jul 6, 2023

Alternatively:

    pre_init:
      - text: |
          # One time initialization for all event receivers
          ErTimeProviderInit {{ priority }}
          installLastResortEventProvider
          syncSysClock

@GDYendell
Copy link
Member

I think allow arbitrary text for edge cases, but use of function should be encouraged for consistent formatting when possible.

@gilesknap
Copy link
Member Author

After pydantic conversion I will complete this Issue by implementing Tom's suggestions as follows:

  • pre_init, post_init become list of script_entry which can have any combination of
    • function: function_name
    • comment: comment_text
    • text: raw_text
    • args: list of args as before - errors if function name not supplied
    • when: defaults to every

If you supply all of function, comment, text they appear in alphabetical order.

Functions get auto generated comment above first invocation, but not if there are zero arguments

@gilesknap
Copy link
Member Author

Do this before J20

@gilesknap gilesknap added this to the Pre J20 milestone Sep 13, 2023
@gilesknap
Copy link
Member Author

I have a new proposal to simplify this down to just pre_init and post_init text. See #72 (comment)

pre_init:
- type: text 
  when: first / last / every
  value: |
  # my comment can go here
  myfunc(1, 2, {{arg}}, 4) 
  more_funcs_as_needed()
pre_init:
  AS ABOVE

@coretl
Copy link
Contributor

coretl commented Sep 25, 2023

Suggest:

pre_init:
- when: first / last / every
  text: |
  # my comment can go here
  myfunc(1, 2, {{arg}}, 4) 
  more_funcs_as_needed()
pre_init:
  AS ABOVE

@gilesknap
Copy link
Member Author

All done in #109.

pre_init / post_init are Union[text, comment] but type defaults to text so you can write:

pre_init:
- value |
  My Multi-line
  Text

with type=text and when=first being the defaults

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants