Github Copilot Usage

Introduction

This notebook will go over usage of github Copilot for Open Source projects which are part of a eco-system of other projects within a standards body.

An initial aim is to find out it's usefulness for MaterialX code development. The hope is that since it is using OpenAI Codex that it can leverage existing open source github repositories for MaterialX as well as related ASWF projects.

We concentrate on source code since that appears to be the main focus of Copilot . When asked non programming questions Copilot will reply: Sorry, but I can only assist with programming related questions. Strangely the prompt `What is the latest version of MaterialX`` returns this answer?

As a complimentary tool, the public beta of Copilot Chat was also installed.

See Sectup section at the end test setup for Visual Studio / Visual Studio Code.

Gating Factors

We will look at the following factors

• Validity and Correctness: Can code and documentation be generated that is correct and from a validated source?
• Accountability: If code is generated can it be traced back to the original source?
• Efficiency: Can it save time and effort in development?
• Standards: Does it follow the standards of the project, standard body?
• Security: Does it introduce security risks?
• Relevance: Does it provide suggestions that are up-to-date and relevant to the project?
• Repeatability: Can it be used to repeat the same task over and over again with consistent results?

Note that this notebook was written with Copilot enabled to test it's usefulness in assisting with writing documentation.

The general suggestion is to selectively enable Copilot as it can branch off and suggest text and code which can have no relevance to the task / topic at hand. This is due to lack of context provided in the instruction for Copilot. This includes currently logged issues where only the visible editor text is scanned for context.

Correctness and Repeatability

In it's current state this is one of it's greatest failings. For the most part without providing any custom training data Copilot will:

• Generate code or documentation
• Complete code or documentation for APIs which do exist or uses code from an unrelated API.

This is not just returning the incorrect version of a call but instead creating non-existent code calls.

This not only extends to MaterialX specific code, but also to code from other projects and even established APIs such as Python and Javascript. It sometimes will generate calls for one API based on existing calls for another API which greatly lowers the trust factor.

Below is a trivial example using comments as hints for code generation.

getDefinitions() does not exist in the API but is suggested by Copilot. The same is true when asking to create a definition.

import MaterialX as mx

# Create a document.
doc = mx.createDocument()

# Find all definitions in the document.
def_list = doc.getDefinitions()

# Create a new definition.
def_ = doc.addDefinition("my_def")

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[5], line 7
      4 doc = mx.createDocument()
      6 # Find all definitions in the document.
----> 7 def_list = doc.getDefinitions()
      9 # Create a new definition.
     10 def_ = doc.addDefinition("my_def")

AttributeError: 'MaterialX.PyMaterialXCore.Document' object has no attribute 'getDefinitions'

One useful task would be for generation of test code for existing APIs. But this cannot even be considered since the code generated will mostly likely be invalid.

In terms of code completion, it fairs a bit better. At this time of writing the MaterialX Python libraries are not documented. After using Co-Pilot for a while it was able to suggest API calls and argument completions. An example is shown below of additional suggestions added for Document calls.`

For the example below, it was able to suggest the correct call node graph creation, but the complete code including the import and doc creation must be visible on screen and within the same notebook cell for this to work. Sometimes it will just not come up with anything so there is a repeatability issue.

When correct it can save quite a bit of time, but it can waste just as much time by inserting calls or arguments which do not exist in the API. The hope is that correctness and repeatability will improve over time.

import MaterialX as mx
doc = mx.createDocument()

# Create a new node graph.
graph = doc.addNodeGraph("my_graph")
# Print graph name
print(graph.getName())

my_graph

Use the Co-Pilot action to "fix" or explain code is mostly of no use as it will return generic information about language or environment syntax and not anything specific to the code.

For example querying to "explain" the document doc. returns generic information about the need to call a member function, and the "fix" action actually fairs no better, reusing the same non-existent API calls.

Using Chat is not recommended. It is unknown how the response is generated but it is unusable. As an example the prompt was on how to create a node definition. The example XML returned was:

<NodeDef id="myNode" type="float">
  <Input name="input1" type="float" />
  <Input name="input2" type="float" />
  <Output name="output" type="float" />
  <ShaderStage stage="pixel">
    <ShaderCode>
      <![CDATA[
        $output = $input1 + $input2;
      ]]>
    </ShaderCode>
  </ShaderStage>
</NodeDef>

For example the embedding of shader code inside is purely fictitious as is it's explanation: Using Chat is not recommended. It is unknown how the response is generated but it is pretty well always | unusable. As an example the prompt was on how to create a node definition. The example XML returned was:

The ShaderStage element specifies the shader stage where the node will be used, and the ShaderCode element contains the shader code that implements the node's functionality. In this case, the node simply adds its two input values together and outputs the result. Note that this is just a simple example, and MaterialX supports much more complex node definitions with multiple shader stages, conditional branching, and other advanced features.

Accountability

It is important to be able to provide accreditation for any code that is used. This is not possible with Co-Pilot. It is unknown how the code is generated and it is not possible to trace the code back to the original source.

Efficiency

For efficiency and accuracy, it is much faster to build symbols for a project and use the existing non-Co-Pilot code completion. There are no assumptions as to what code API and version of code to use as this is part of the project itself.

Standards

There does not seem to be any way to provide formatting rules for Co-Pilot (e.g. such as a Clang format file). When asked to format code it uses some unknown formatting convention. For this aspect it is not worth using Co-Pilot for such as task. Naming convention also seems not possible to perform. Other small consistency items such as adding in a default copyright appears to also not be possible.

There is no way to add in requirements for version of compiler, platform, and other build dependencies including what test harness is being used. As such it is possible to have code which is compliant being suggested which will not compile or run.

For examine move semantics are suggested for performance on a given function, but this may not be available. (For this example it could not parse the function signature correctly and suggested acting on non-existent arguments.)

Relevance

Using fixed data is one of the major drawbacks. It appears to be possible to add in additional data but this has not been attempted for Copilot or any other LLM.

Repeatability

This is a general issue that tuning can help to alleviate but just from Visual Studio (Code) integration it is not possible to tune these parameters.

Appendix: Setup

As a setup step, the Copilot and Chat plugins need to be installed.

The chat interface for Copilot is available by signing up for the beta program at this time of writing. The chat feature can be used in a similar way to ChatGPT but within the context of a working environment. This has the added advantage of avoiding some context switching. (There are ChatGPT and other unofficial add-ons which are available but not considered here.)

The following is a snapshot with and chat add-ons installed:

If chat is setup, for the Visual Studio Code integration a new tab on the left is available where prompts may be entered.

Unlike code completion, the responses need to be migrated to their intended location. Options (highlighted on the left) include:

• Inserting into the editor at a location
• Export to file
• Running from terminal.

The last option (Running from terminal) only makes sense for code which can run as a command. At the current time the response is not checked to see if it's runnable.

Copilot can be turned on or off via the icon highlighted on the bottom right.