// Find and configure extension
        extensions.findByType(type)?.let(configuration)
            ?: Factory {
                // Find and configure convention
                // Reflective look up to still support plugins that inlined this function once conventions will be removed
                this::class.java.methods
                    .firstOrNull { it.name == "getConvention" }
                    ?.invoke(this)

	req  clientRequest
	resp clientResponse

	// JSON-RPC responses include the request id but not the request method.
	// Package rpc expects both.
	// We save the request method in pending when sending a request
	// and then look it up by request ID when filling out the rpc Response.
	mutex   sync.Mutex        // protects pending
	pending map[uint64]string // map request id to method name
}

// union of types (tensorflow::Value). This effectively requires moving much of
// the implementation of function.py/def_function.py to C++, and exposing a
// high-level API here. A strawman for what this interface could look like:
// TF_Value* TF_ExecuteFunction(TFE_Context*, TF_ConcreteFunction*, TF_Value*
// inputs, int num_inputs, TF_Status* status);
TF_CAPI_EXPORT extern TFE_Op* TF_ConcreteFunctionMakeCallOp(

        deps = [
            "//tensorflow/cc/framework/fuzzing:cc_op_fuzz_gen_main",
            op_def_src,
        ] + kernel_deps,
    )

    # Add relevant locations to look for api_defs.
    api_def_src_locations = ",".join(["$$(dirname $$(echo $(locations " + api_def_src + ") | cut -d\" \" -f1))" for api_def_src in api_def_srcs])

    out_fuzz_files = [op_name + "_fuzz.cc" for op_name in op_names]

			// by construction.
			panic("bug in runtime/metrics package!")
		default:
			// This may happen as new metrics get added.
			//
			// The safest thing to do here is to simply log it somewhere
			// as something to look into, but ignore it for now.
			// In the worst case, you might temporarily miss out on a new metric.
			fmt.Printf("%s: unexpected metric Kind: %v\n", name, value.Kind())
		}
	}
}

  // expected to interact with it to perform any changes to the IR from here.
  mlir::LogicalResult matchAndRewrite(
      mlir::tfd::ConvertTftToDhtOp op,
      mlir::PatternRewriter& rewriter) const override {
    // Look through the inputs of the ConvertTftToDhtOp.
    mlir::Value convert_op_input_0 = op.getOperand(0);
    mlir::Value convert_op_input_1 = op.getOperand(1);
    mlir::tfd::MoveDhtToTftOp move_input_op_0 =

import org.apache.maven.model.building.ModelProblemCollector;

/**
 * Handles normalization of a model. In this context, normalization is the process of producing a canonical
 * representation for models that physically look different but are semantically equivalent.
 *
 */
public interface ModelNormalizer {

    /**
     * Merges duplicate elements like multiple declarations of the same build plugin in the specified model.
     *

The settings file is typically found in the root directory of the project.

Let's take a look at an example and break it down:

====
[.multi-language-sample]
=====
.settings.gradle.kts
[source,kotlin]
----
rootProject.name = "root-project"   // <1>

include("sub-project-a")            // <2>

  // Returns a map from variable names to their data types.  Slices of a
  // partitioned tensor are combined into a single entry.
  const TensorSliceReader::VarToDataTypeMap& GetVariableToDataTypeMap() const;

  // Attempts to look up the tensor named "name" and stores the found result in
  // "out_tensor".
  void GetTensor(const string& name,
                 std::unique_ptr<tensorflow::Tensor>* out_tensor,
                 TF_Status* out_status) const;

### Project file structure

Let's say your project file structure looks like this:

```
.
├── app
│   ├── __init__.py
│   ├── main.py
```

Now create a directory to store those static files.

Your new file structure could look like this:

```
.
├── app
│   ├── __init__.py
│   ├── main.py
└── static/
```

### Download the files