---
# System prepended metadata

title: '[Notepad] ytt Notes — GC & VM'

---

# [Notepad] ytt Notes — GC & VM

## ytt

#### Assertion

assert.go
beware of overlay/assert


---
#### openAPI schema
3.1
examples next to entire schema object	example within schema object (next to a property)
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#exampleObject	example: *value*

---
#### How to set up shell completion

BASH
Linux:
  $ ytt completion bash > /etc/bash_completion.d/ytt
MacOS:
  $ ytt completion bash > /usr/local/etc/bash_completion.d/ytt

ZSH
Linux:
$ ytt completion zsh > "${fpath[1]}/_ytt"
macOS:
$ ytt completion zsh > /usr/local/share/zsh/site-functions/_ytt

FISH
$ ytt completion fish > ~/.config/fish/completions/ytt.fish

POWERSHELL
C:\> ytt completion powershell | Out-String | Invoke-Expression
To load completions for every new session, add the output of the above command
to your powershell profile.

---
#### Annotation Positions

#472 Feedback from Dmitriy
- achieve what we want with fields in position
- more maintainable if what we put into the error was enough context to recreate the info
- let go of trying to collect the exact pos, but capture the {key: value} in the error move 

writeup:

After syncing up with @cppforlife we concluded about a few things:
- in library evaluations, there is a [starlark eval error](https://github.com/vmware-tanzu/carvel-ytt/blob/develop/pkg/template/compiled_template_error.go#L55) that is being returned, which contains a stack trace, starlark knows how to report these errors using the stack after they occur
- in oct 2019 there was a [starlark release that adds an "cause" field](https://github.com/google/starlark-go/commit/58de16fb0ee76530b35384f2854db6b4e0004ea0) that might allow us to have the schema error and inject information before calling the .Error() function on the schema error
- trying to "guess" on filename and function could be problematic, let's never report incorrect information in our errors, and grabbing file name or line number from the `thread` or `args` variables is not guaranteed to be correct - we can always create an example that would show this.
- helpful information to include in the schema error is the failing key. So, I'm going to investigate providing that information.
- as a continuation of this story, we should see if the starlark update would actually provide us with the ability to fill the error with correct information.

---
#### ip address parsing
- CIDR, which stands for Classless Inter-Domain Routing, is an IP addressing scheme that improves the allocation of IP addresses. It replaces the old system based on classes A, B, and C. This scheme also helped greatly extend the life of IPv4 as well as slow the growth of routing tables.

notes:
parse_ip() returns "" when invalid ip string is passed

---
Broken Link on develop: https://github.com/k14s/ytt/blob/develop/examples/playground/example-ytt-library-module … found at bottom of page : https://github.com/k14s/ytt/blob/develop/docs/lang-ref-ytt-library.md 

---

#### Schemas
- Type check in go using interface.(type)
- We mark the files as “not for output” by iterating through them
- Using overlays to implement all of schemas?
    - Is this the right thing to do? 
    - Overlays are a first class concept in ytt (templates, overlays, data values)
    - Schemas should also be one of these “first class concepts”, so probably don’t use overlays to implement them.
- *.with_data_values() function on loaded yet libraries.
- DataValuesPre-Processing!!!!!
- Collect all the errors when validating against a schema.
- What about intermediate representation? Fail on those?
- What if you include a data value file that includes the library reference?
- We can’t use 
- from 10/1/20

---

#### Overlay Error Messages
- Assumptions about what kinds of error messages works best for different scene
- Generating assumptions of what we think to be true - then reword that assumption so that we can confirm or deny them. 
- Just start writing down assumptions that we have
- What you think is true
- “People user prefers minimize error message because it is easy to read”
- “Users don’t like minimalists because it doesn’t give enough info to move on with debugging”
- Ask them to say what they are thinking

How do we want to validate that…
1. Craft the scenario
2. Given you saw this error message:
3. Give a user a task
4. Give a prompt : given you are working for overlay for this use case. Image that you see the screen: blah
5. What would you do next.
6. Back and forth. Tell me what’s next. 
7. Imagine that didn’t work - tell me what you would do next
Timebox: 30 mins


More work: identify groups of people
Provide all the things needed for someone to run the experiment 

Meesage to Slack: Hey y’all! We on the Carvel team are looking for users to help improve the ytt overlay error messages. We have created a proposal for some new error messages and wish to get some feedback. Please reply to this thread, or dm me or Helen directly if you want participate in user testing some time in the future. 


### Goland

| Command | Outcome |
|---------|---------|
|option+command+n |	Inline variable definition and next line |
|option+command+v |	Create variable in front of expression |
|option+command+m |	Extract function |
|command+d |	Duplicate line, see changes of git commits add method to interface + implementations |
|control + g |	find and select the next occurrence of case-sensitively matching word or text range |

