profile
viewpoint
Marcel van Lohuizen mpvl Google Zurich, Switzerland

mpvl/errd 153

Package errd simplifies error and defer handling.

mpvl/errc 67

Package errc simplifies error and defer handling.

cuelang/cuelang.org 14

Source for the cuelang.org site

mpvl/unique 8

Package unique provides primitives for finding unique elements of types that implement sort.Interface.

cuelang/lang-js 7

CUE bindings for JS

mpvl/google_auth_proxy 1

A reverse proxy that provides authentication using Google OAuth2

pull request commentcuelang/cue

doc/tutorial/: Update import label format.

Note that the examples in the docs are run through a simulator, which is why these tests are failing.

phaer

comment created time in a day

pull request commentcuelang/cue

doc/tutorial/: Update import label format.

The format has changed for the next release as part of a big cli-tool overhaul. As the Kubernetes documentation on cuelang.org is automatically synced to the latest version (should be a copy of a specific version), it may be out of sync.

The correct fix would be to copy over the kubernetes docs in the build script in cuelang.org.

phaer

comment created time in a day

push eventcuelang/cue

Grant Zvolsky

commit sha bfdc42340876a79da5eb52477cfb04f5e096968c

cmd/cue/cmd: prevent infinite loops while building dependency graph The existing implementatin resulted in an infinite loop in two cases: 1. In the v.Equals(after) call when the 'after' dependencies were cyclic 2. In the task.Walk function when task fields cyclically referenced other tasks This commit solves both cases by - stepping out of the Walk lambda when it had already been evaluated with the given parameter; and - removing the special case for 'after' dependencies as it is no longer necessary. Relevent tests are included. Updates #245 Change-Id: I914ff9aad96eb43ae89964000dea60ccd44c38a2 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4910 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a day

push eventcuelang/cue

Marcel van Lohuizen

commit sha 0846b9324399ff782fcc38e0c156f418910b361c

cmd/cue/cmd: add --tags flag The tags flag allows specifying values for fields. Issue #190 Issue #159 Change-Id: Iddbfe8eb9fcb2a163ce773411042e020372ff8be Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4949 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a day

push eventcuelang/cue

Marcel van Lohuizen

commit sha 511584ef91b9d63f60a2a6dc0f67d65efae45924

cmd/cue/cmd: allow top-level tasks This will allow tasks referring to some shared top-level task, like `env`. Tasks are only enabled if explicitly referenced. Change-Id: Ia05b2ecb1f9140a39ba70a8a41b94a4733d4eda8 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4908 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a day

push eventcuelang/cue

Marcel van Lohuizen

commit sha 520895661175664c16e9bb252db7f14955b6564d

cmd/cue/cmd: add safeguard to trim operation Compare output of generated trim to ensure the results are identical. Issue #277 Change-Id: I96c0eeb960d34141dc8de0f60c2d5102b164501c Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4909 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 429bd0ffea0924f2c43c51359f1ad08513ac7af0

internal/filetypes: package for interpreting command line args The idea is that the build.File type will be added to the build.Instance type, replacing the current file specs. It will be populated by the load package. The command line tool can subsequently use this package to determine settings on how to interpret build.File. It is a separate internal package so that the API can be shared by load and cmd. Issue #280 Issue #254 Issue #183 Issue #130 Issue #116 Change-Id: I47f2391945113fe664f0ec33b0048be70326edb5 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4946 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>

view details

push time in a day

push eventcuelang/cue

Marcel van Lohuizen

commit sha 0afa3779c9f8e7c26644729b9cfcdaf15fa4f3f3

pkg/list: fix typo Change-Id: I9becdc016839e1a7d4ae7302be265ffe489e1753 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4980 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 0308a538dfc9a6aa4afbfaf3b8239a94b5ec409e

encoding/gocode: make work for definitions The Go code could only be correlated with values so far. Allow either. Change-Id: I3ebf8fd532a66eb11fe933f8e40a8e28b8eb5c42 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4981 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a day

push eventcuelang/cue

Marcel van Lohuizen

commit sha 5c3a17baeb02fc5c3638e8a28a574944f211e66e

internal/diff: fix bug that caused hang Change-Id: I97cf08d2dfe6064533d048bb140a5e8524fb7c00 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4948 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 6 days

push eventcuelang/cue

Daniel Martí

commit sha 066ede6ca14ddbca75b760fad01657242725dce5

all: gofmt -s While at it, remove a couple of unused code low-hanging fruit. Change-Id: Idcca881c8496f7a102ce84f1434dfb1e441b8eb9 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4921 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Daniel Martí

commit sha 107863a76cf05f14fb4c09b20bf8e8ee3e14dba4

doc/ref: fix a go-ism in the spec It seems like it used ':=' instead of ':' by mistake. Change-Id: I6f1694b029b43bb417c10c44048bd3976d4bb867 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4920 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Daniel Martí

commit sha e6c7748cac3d8ccb03314ac01accdad2ce46f743

.github: small improvements to the bug template First, add a note about 'cue version' showing no version information if one builds from source. Second, remove the operating system question, as 'cue version' already shows the equivalent of GOOS/GOARCH. Change-Id: Id71516aaa529240b36a8b2e9491ac51c7095a607 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4922 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 6 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 58ada0ed5f251eee51c45b7fed80731c36562b2e

cue: define Fill on Value, LookupDef and bug fixes Change-Id: I957956fb9bcfc531ad19baaa294c66ebf91daae9 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4945 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 442518f7e941f87a507386eb697cb3ec7aa154f4

cue/errors: make compile again with Go 1.12 Change-Id: I7f18c140ddba8dedbb9584c95021163c48ddbcdd Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4947 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 6 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha c3c1624948784351744b766e90fed51bc3de5211

cue: keep path in API error value Change-Id: Ib5fbeec7a7a8c826335f08335b40de597963b2c9 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4940 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 0e4130ffd97d3ec2541474400bc987cb4c715a30

doc/tutorial/basics: remove reference to % operator Change-Id: I86279e73f546487953c50a432c1a398b8e8ecf51 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4941 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 0cb140ec8981d9a76f05b984969833b153688e8d

doc/ref/spec.md: reformat to deal with Hugo bug Change-Id: Id006aa7ffea6050b89319cfe71d6517e834db37a Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4942 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha c22d46db022ef5dd760b128c95e8ae188b9a5b49

pkg/tool/os: remove env manualipulate tasks Change-Id: Ieda7d1e6b0836384ffbce9f1557ea85ca3ed0c8e Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4943 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha e084198e0879ba2747ca54789bdfe234514aa670

cue: fix compiler bug and improve debug print empty labels were dropped by compiler non-identifier keys are printed as strings Change-Id: I1523114046301d87b8186d68b6865f1dbb144a79 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4944 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 6 days

issue commentcuelang/cue

cue export --output=list for ldjson format

FYI, if the list tag were to be supported in the current command line syntax, one could indeed write -o list+stream:foo.json to override writing multiple values to a JSON file (invalid JSON), or write -o list:foo.yaml or -o list:foo.jsonl. Maybe list should be the default for jsonl files, but that would mean that the output will be expected to be a list and not a stream. That said, the mechanism already allows different defaults for different operational modes, so it is not out of the question. But it should become too magical.

mikelnrd

comment created time in 7 days

issue commentcuelang/cue

cue export --output=list for ldjson format

So IIUC, --list takes a stream and interprets it as a single list value. So the idea is that if the output of CUE is a list, the --list flag, so some list label would cause a list to be exported as a JSON stream. I think it would be best in that case to generate an error if the generated value is not a list.

We could indeed also go off the file name. This is a bit trickier. The CUE tool allows streaming semantics without interpreting it as a list (e.g. for vet). So it may be strange to interpret .ldjson or .jsonl files as lists by default. Conversely, one should then also not assume list semantics when outputing by default, I think. Actually, I think the file.ldjson is already supported, but one would need to use --list.

mikelnrd

comment created time in 7 days

issue commentcuelang/cue

cue.Instance.Fill() fails when multiple level of definitions are involved

This is actually an evaluation bug, interpreting closedness too strictly. A workaround is given below.

In short: literal structs within definitions (such as Mid) are closed when the construction of the definition is complete. In this case, however, the closedness happens before the optional fields are merged, causing the interpretation to be too strict.

The following snippet reproduces it for cue eval

TopLevel :: [name=string]: {
	path:    string
	content: string
}

Mid :: TopLevel & {
	myoutput: path: "/output"
}

val: Mid & {} & {myoutput: {content: "foo"}} // Should work.

The workaround for now is to "open" the literal struct. As embeddings are not closed, you can write:

Mid :: TopLevel & {{
	myoutput: path: "/output"
}}

Alternatively, you could not declare "Mid" as a definition.

aluzzardi

comment created time in 7 days

issue commentcuelang/cue

cmd/cue: unexpected result from two-stage comprehension

From Slack: Currently, all comprehensions are evaluated before they are mixed in. This means that the second comprehension cannot see the y inserted by the first one. However, it probably makes more sense to adopt a fixed-point semantics, where embeddings and comprehensions are evaluated until a fixed point is reached. There is also an odd consequence with the current semantics where comprehensions may be evaluated anyway if structs with comprehensions are passed around, effectively executing the next step in a fixed-point computation.

rogpeppe

comment created time in 7 days

issue commentcuelang/cue

cmd/cue: fmt doesn't align definitions very well

Yeah. Another thing to consider is to space

a: bbb:  int
ccc: dd: 5 

as

a:   bbb: in
ccc: dd:  5

This may not work well if the fields are too different in size, but the latter seems to be better in general.

At some point the formatter should be completely rewritten. The current one is a fork from the Go one, but CUE underwent some changes that should make formatting much simpler: it has relative positioning, there is no need to use absolute positions, there are no more block comments, etc.

mvdan

comment created time in 7 days

issue commentcuelang/cue

cmd/cue: fmt doesn't align definitions very well

That seems reasonable. The alternative is to not have a space between the field name and the double colon.

mvdan

comment created time in 7 days

push eventcuelang/cuelang.org

Marcel van Lohuizen

commit sha ed20e368cb6888a20ff4bba3736b0e8e44094890

all: update to new syntax

view details

push time in 9 days

PR merged cuelang/cuelang.org

all: update to new syntax
+15 -15

0 comment

7 changed files

mpvl

pr closed time in 9 days

PR opened cuelang/cuelang.org

all: update to new syntax
+15 -15

0 comment

7 changed files

pr created time in 9 days

push eventcuelang/cuelang.org

Marcel van Lohuizen

commit sha 7ef21dbb2e83a881525319bee2ad1862811010a3

all: update to new syntax

view details

push time in 9 days

push eventcuelang/cuelang.org

Marcel van Lohuizen

commit sha e61934dc0f17006bcb32fd6a39e65b9e47fe78f3

docs/concepts/logic.md: fix graph

view details

Marcel van Lohuizen

commit sha 73c2530c57667820ed9ba029112f428bbaad10db

src/cue: update submodules And why does this need to be so difficult!

view details

Marcel van Lohuizen

commit sha 280425cf62651a7bb5d4e2b3420b408b8b0fa90d

all: remove cue submodule

view details

Marcel van Lohuizen

commit sha b9568033da2617be7b9e01f19f417881d47eebf5

build.sh: use clone instead of git modules.

view details

Marcel van Lohuizen

commit sha 63af8bf93501fa64cecf0633553e7fd3b8770f85

build.sh: move src directory Move cue directory somewhere else, because there seems to be no way to test this transition on Netlify.

view details

Johan Euphrosine

commit sha e06f6d4f34232e55147e52ee59227ae068a4c991

docs/integrations/openapi: fix broken link

view details

alonamit1729

commit sha 8ac22f0f947c751ea67437a55ece9922696c2d47

Update logic.md Fixed some typos.

view details

Johan Euphrosine

commit sha 42fa00d8173d46c426ee4efd56790c3348eba53d

docs/integrations/openapi: fix code snippet

view details

Marcel van Lohuizen

commit sha d5e0a2df2496674254019163d8ed83e955a6b12c

all: update to new syntax

view details

push time in 9 days

push eventcuelang/cuelang.org

Marcel van Lohuizen

commit sha 0d16d7614d959333addd8867a058d6bda3a9923e

all: update to new syntax

view details

push time in 9 days

push eventcuelang/cuelang.org

Johan Euphrosine

commit sha 42fa00d8173d46c426ee4efd56790c3348eba53d

docs/integrations/openapi: fix code snippet

view details

push time in 9 days

PR merged cuelang/cuelang.org

docs/integrations/openapi: fix code snippet

Without this compiling the snippet fails with:

./gen.go:11:37: syntax error: mixed named and unnamed function parameters
+1 -1

0 comment

1 changed file

proppy

pr closed time in 9 days

push eventcuelang/cuelang.org

alonamit1729

commit sha 8ac22f0f947c751ea67437a55ece9922696c2d47

Update logic.md Fixed some typos.

view details

push time in 9 days

PR merged cuelang/cuelang.org

Update logic.md

Fixed some typos.

+8 -8

3 comments

1 changed file

alonamit1729

pr closed time in 9 days

push eventcuelang/cuelang.org

Johan Euphrosine

commit sha e06f6d4f34232e55147e52ee59227ae068a4c991

docs/integrations/openapi: fix broken link

view details

push time in 9 days

PR merged cuelang/cuelang.org

docs/integrations/openapi: fix broken link

Grüezi! ( long time no see ;)

+1 -1

0 comment

1 changed file

proppy

pr closed time in 9 days

pull request commentcuelang/cuelang.org

Don't use submodules for CUE and fix typo in graph

@JnRouvignac sorry I forgot to push this, was convinced it was already done!

mpvl

comment created time in 9 days

push eventcuelang/cuelang.org

Marcel van Lohuizen

commit sha e61934dc0f17006bcb32fd6a39e65b9e47fe78f3

docs/concepts/logic.md: fix graph

view details

Marcel van Lohuizen

commit sha 73c2530c57667820ed9ba029112f428bbaad10db

src/cue: update submodules And why does this need to be so difficult!

view details

Marcel van Lohuizen

commit sha 280425cf62651a7bb5d4e2b3420b408b8b0fa90d

all: remove cue submodule

view details

Marcel van Lohuizen

commit sha b9568033da2617be7b9e01f19f417881d47eebf5

build.sh: use clone instead of git modules.

view details

Marcel van Lohuizen

commit sha 63af8bf93501fa64cecf0633553e7fd3b8770f85

build.sh: move src directory Move cue directory somewhere else, because there seems to be no way to test this transition on Netlify.

view details

push time in 9 days

issue commentcuelang/cue

spec: part of struct section renders badly

Seems to be (one of the many) Hugo bugs. I'll try triple quoting

rogpeppe

comment created time in 9 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 8fbf67e1b260c439e498e0ccf27bb6cd0bd2c0bc

cmd/cue/cmd: improve $after semantics and errors - report error if not a reference - reference must be exact (may not point inside task) - reference may refer to task group Issue #245 Change-Id: Ib210ab38e0cb6bb750d4c020f9e7138442169ac3 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4906 Reviewed-by: Grant Zvolský <grant@zvolsky.org> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha dd87908df1177cfbfddd6911d5634d55c6c55a53

cmd/cue/cmd: make task references absolute This prepares for allowing top-level tasks and a more general task specification overall. Change-Id: I45fd9eed123026da6db09a2a13bcba512dafb75b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4907 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 9 days

issue commentcuelang/cue

command/task evaluation concurrency issue

@jlongtine you may be interested in this as well.

grantzvolsky

comment created time in 11 days

issue commentcuelang/cue

command/task evaluation concurrency issue

See https://cue-review.googlesource.com/c/cue/+/4906. This improves error messages and allows depending on a group of tasks.

grantzvolsky

comment created time in 11 days

issue commentcuelang/cue

cmd/cue: trim: format an empty struct without an extra line

The easiest fix seems to be formatting {} on a single line. I'll be down for that if there are no objections.

rogpeppe

comment created time in 11 days

Pull request review commentcuelang/cue

encoding/cue: Enable printing of CUE values

+// Copyright 2018 The CUE Authors+//+// Licensed under the Apache License, Version 2.0 (the "License");+// you may not use this file except in compliance with the License.+// You may obtain a copy of the License at+//+//     http://www.apache.org/licenses/LICENSE-2.0+//+// Unless required by applicable law or agreed to in writing, software+// distributed under the License is distributed on an "AS IS" BASIS,+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.+// See the License for the specific language governing permissions and+// limitations under the License.++package cue++import (+	"cuelang.org/go/cue"+	cueformat "cuelang.org/go/cue/format"+)++// Marshal returns the CUE encoding of v.+func Marshal(v cue.Value) (string, error) {

We need to know what the users wants: data or schema. With eval there are options to guide this to some extent, but this is even not enough. It seems that there are primarily two modes (data and schema/all) for export. This needs to be reflected in the API somehow.

It can be with options, e.g. cue.Marshal(cue.Data, x) or with different functions MarshalData cue.MarshalSchema, etc. Or a combination of the two.

I have a slight preference for configuration, as there are actually more than two types. (Data, Graph, Schema, Struct, maybe more). On the other hand, these really classify into two modes, each with different options, so it is fine, for now, to just have MarshalDef and MarshalData (or just the one you need) with a dummy placeholder for further configuration. Several other APIs, like encoding/base64, already have such a dummy conversion.

So func Marshal(config, v cue.Value) (string, error) or func Marshal(Def|Data)(config, v cue.Value) should be the API, I reckon. Suggestions welcome of course.

jlongtine

comment created time in 11 days

Pull request review commentcuelang/cue

encoding/cue: Enable printing of CUE values

+// Copyright 2018 The CUE Authors+//+// Licensed under the Apache License, Version 2.0 (the "License");+// you may not use this file except in compliance with the License.+// You may obtain a copy of the License at+//+//     http://www.apache.org/licenses/LICENSE-2.0+//+// Unless required by applicable law or agreed to in writing, software+// distributed under the License is distributed on an "AS IS" BASIS,+// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.+// See the License for the specific language governing permissions and+// limitations under the License.++package cue++import (+	"cuelang.org/go/cue"+	cueformat "cuelang.org/go/cue/format"

Just format is sufficient if there is no ambiguity.

jlongtine

comment created time in 11 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha f8afaed0bbb7b8383070cb65d29b3365eb5dc895

cmd/cue/cmd: simplify usage of --path flag Closes #176 Issue #193 Change-Id: I95609cec93b0429470f1d7342ab12d45fd9207c7 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4905 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 11 days

issue closedcuelang/cue

cmd/cue/cmd: make import path specification more shell friendly

the restructuring with -l is not working on windows with the given examples

cue import -l '"\(name)"' test.yaml 

with a test.yaml of

name: test
value: whatever

always results in

parser error in path "\\(name)": illegal character U+005C '\'

i think this should be working as the documentation states U+005C as the right character to start string-interpolation. tried on last release.

closed time in 11 days

cHolzberger

issue commentcuelang/cue

Allow access to any field in current value when importing

With a few upcoming changes this will become easier. Firstly, there will be a --with-context that will evaluate expressions not directly in the data, but in a struct with several fields, including metadata like filename and data for contents. This makes @type not a top-level field, which means it can be accessed as data["@type"]. A sneaky way around the problem, but it works. :)

Also, the --path flag will be simplified a bit: multiple labels are written as multiple uses of the -l flag, each having its own expression.

epcim

comment created time in 11 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha d10e59f34bc2b89b0e5617c01926363bd3b88b69

cmd/cue/cmd: add --with-context flag for import This is relevant for computing labels. Instead of evaluating labels within the context of an imported file, it evaluates it within a struct wrapper where the file contents are assigned to data, while other contextual information, like filename is added. Fixes #193 Change-Id: Iad8119c86c8a64ba1c8f071c87970d4acdf87a0e Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4904 Reviewed-by: roger peppe <rogpeppe@gmail.com>

view details

push time in 11 days

issue closedcuelang/cue

Allow access to any field in current value when importing

Input:

$ head -n 10 profiles/00-fluentbit-gc-profile.yaml
'@type': schema.xyz.io/xyz.io.deploy.profile.Object
systemMetadata:
  uid: 89fe647c-0287-41c9-87e4-d3e9af82f950
metadata:
  name: fluentbit-profile
  uid: 89fe647c-0287-41c9-87e4-d3e9af82f950
spec:
  profileSpec:
    fluentbit:
      fluentbit_namespace: monitoring

Import:

cue import ./profiles/... -p profile -l '"\(strings.Split(@type,".")[5])" "\(metadata.name)"' -f -R                                        
parser error in path "\"\\(strings.Split(@type,\".\")[5])\" \"\\(metadata.name)\"": invalid attribute: expected '('

or

$ cue import ./profiles/... -p profile -l '"\(strings.Split(type,".")[5])" "\(metadata.name)"' -f -R 
reference "type" not found:
    <path flag>:1:18

Is there a way to escape etc?

closed time in 11 days

epcim

issue commentcuelang/cue

command/task evaluation concurrency issue

Yeah, that would be great. Is $after: taskGroup documented to work? It would either way indeed be pretty useful.

Thanks!

grantzvolsky

comment created time in 11 days

issue commentcuelang/cue

cmd/cue: cue trim does not guarantee unchanged output

In addition, trim should really run a before and after diff to verify its results are correct as an extra safeguard.

rogpeppe

comment created time in 12 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha b8cad1ac0d79d939b7f08601b31f098926c4cfb3

internal: hoist attribute parsing logic Change-Id: I76b2163dc717aba19a51b9daa0544792c7a8d599 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4900 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha aae80a0d0427581fa89df80cd03167759a58e67e

internal/cli: hoist cli parsing code from tool/env Change-Id: I4983d7e1dd13816b4bb2db798b87bfb421ffb52b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4901 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha b236d4ad6e42511588ad3b81f46ba792015d9a94

cue/ast: add NewStruct helper Change-Id: Ie6acb637416a2be06325362346b6aad0bc702ed7 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4902 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha e803ab87824c8837431ffe00747f5d588ff50361

cue/ast: add NewLit helper Change-Id: I36810984e1b6e8ad164263510ff8fc5c31bbb095 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4903 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 12 days

push eventcuelang/cue

Koichi Shiraishi

commit sha ede1e7dfd4079527f0bf4b92da1ba79faf4455d1

github: cache ~/go/pkg/mod Cache ~/go/pkg/mod using actions/cache@v1. And update actions/checkout to v2 for some improved performance. Change-Id: I00b7feaa205593bd56162e6bb89c2ef9c17bbd89 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4780 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 13 days

push eventcuelang/cue

Joel Longtine

commit sha 9242bf517b324e0cb82da88abf2b02f48ac9694e

pkg/file: Fix file.Glob to generate correct CUE structure Closes #274 https://github.com/cuelang/cue/pull/274 GitOrigin-RevId: 45842b704d09c6a267de32664eda73a052d1bb7b Change-Id: I3cf7077aa2c1987c18f9fddd013e8b005dc2280b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4880 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 13 days

starteddhall-lang/dhall-lang

started time in 14 days

issue commentcuelang/cue

Add fucntion for uuidgen

We’re still trying to find a good general data representation for non-hermetic functions. But looking at this again, storing values in a database of some sort seems somewhat out the scope of cue. I wonder if there is a way to invoke a tool more generically, without baking it in to cue directly (using exec or http for instance). How do other languages manage this?

For instance an easy way to do this is cue is to have a tool that generates a cue file that is included.

epcim

comment created time in 18 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 442bf2d94d4a71f63a2ffd28c6e437790fbe3284

cue: interpret nil as _ or top depending on the context. Do not interpret as a disjuntion of both. Fixes #220. Change-Id: If935316e23d12825eda3fa75fea8f95a04d09da3 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4860 Reviewed-by: Marcel van Lohuizen <mpvl@google.com>

view details

push time in 18 days

issue closedcuelang/cue

convertRec and null/nil values

Hi,

I think that Instance.Fill misbehaves on nil-values, as it will be unable to marshal them to JSON or decode them properly. Example:

package main

import (
	"log"

	"cuelang.org/go/cue"
	"cuelang.org/go/cue/build"
)

func main() {
	bctx := build.NewContext()
	cueRuntime := new(cue.Runtime)
	ci, _ := cueRuntime.Build(bctx.NewInstance("test", nil))
	ci, _ = ci.Fill(nil, "test")

	var m map[string]interface{}
	log.Println(ci.Value().Decode(&m))
	log.Printf("%#v", m)
}

// $ go run test.go
// 2019/12/10 14:29:54 cue: marshal error at path test: cannot convert incomplete value "_" to JSON
// 2019/12/10 14:29:54 map[string]interface {}(nil)

From what I understand the bug is in cue/go.go:206: https://github.com/cuelang/cue/blob/275105a3c865a7444b9552bb115ab1c7db3c088b/cue/go.go#L206

// Interpret a nil pointer as an undefined value that is only
// null by default, but may still be set: *null | _.
return makeNullable(&top{src.base()}, false).(evaluated)

According to the comment the default should be null, however it is marked as false. Changing to

return makeNullable(&top{src.base()}, true).(evaluated)

fixes the behaviour, but breaks the test in https://github.com/cuelang/cue/blob/275105a3c865a7444b9552bb115ab1c7db3c088b/cue/go_test.go#L37 which asserts null | _ instead of *null | _.

Which one is/should be the correct behaviour?

Thank you, Bastian

closed time in 18 days

bastianccm

issue commentcuelang/cue

convertRec and null/nil values

I took a deeper look and it turns out to be much trickier. The setting of the default *null interacts poorly if the corresponding value is merged with user values, as it will render any user-specified defaults invalid (or over defined). It also interacts poorly the "complete" functionality. In general, if we allow Go values to be "partial" and use them to compose bigger wholes, then we should not set null as a default.

So the best thing to do seems to be to allow a default null value in the schema (if requested) but to treat nil as undefined in other cases.

So what remains is the question what to do instead. nil can either be null unconditionally, or _, where the latter should mean "undefined" as in it is still open. The latter is the best option if we want to allow composition and is the most compatible with existing code.

Of course I can imagine this is not always the desired interpretation. If the Go value is to be interpreted as a "final" value, nil should be null. This interpretation can still be obtained currently by unifying the resulting value with the the corresponding's type schema (if created with null defaults) and then finalizing the value.

bastianccm

comment created time in 18 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 58cdb7774142d868f69935e1d936a69ac8c0ff72

.github: update issue templates Closes #272 https://github.com/cuelang/cue/pull/272 GitOrigin-RevId: 6638542e60b70af9a3c93a6d0c38a481a6d95ee7 Change-Id: I3184aa660be0ffe78e0e7dd7f84544266776b129 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4841 Reviewed-by: Marcel van Lohuizen <mpvl@google.com>

view details

push time in 19 days

PR closed cuelang/cue

.github: update issue templates cla: yes
+61 -0

0 comment

2 changed files

mpvl

pr closed time in 19 days

issue commentcuelang/cue

Formatter outputs open lists as closed

I think have a go def like @UkiahSmith proposed makes sense. The alternative is having just cue eval (possibly short cue) and have an output mode specifier. Yet another is to have a --def flag that switches the default from data to schema, or something To some extent it makes sense to have one command, as it makes the command line more flexible and there are less commands to learn. But it makes discoverability harder. So a specific def command could be useful, at least as an initial concept.

There are two approaches: this schema output printer is made part of the evaluator overhaul. But by implementing it now we could see if there are any unforeseen issues that could be learned from in doing the evaluator overhaul. So I think my preference is to do it now.

Other than that, I think the right approach is to do this in Syntax (cue/export.go). Essentially, as I see it now, there are really only two common modes: Final(data) and Schema (All). Some specifics of each:

Final/ Data:

  • pick defaults in all cases
  • don't show optional fields and definitions
  • interpret as graph:
    • do not follow references that point to parts of the data that are already included.
    • references to imported data or definitions can be expanded and optionally uniqued if multiple reference to the same nodes exist (that is a bit complicated and not needed initially).

Special options can be added to disallow cycles or to fully expand references. The graph mode should probably be the default for CUE as it is the robust representation. It will allow converting potentially exponential data structures between YAML and CUE in linear time without blowing up. Note that this kind of cycle handling is orthogonal to that in CUE evaluation.

All/ Def/ Full (All already exists as an option):

  • don't pick defaults:
    • leave *1 | int as is
    • don't close open lists [...string]
  • don't follow references
    • ensure imports are included for reference pointing there
  • options can be added to expand reference to imports (SelfContained) and definitions.
rudolph9

comment created time in 19 days

issue commentcuelang/cue

command/task evaluation concurrency issue

@grantzvolsky thanks for digging in to that.

Yes, in tip you can set $after in a task to a list of tasks that should complete before it.

grantzvolsky

comment created time in 19 days

issue closedcuelang/cue

Cue for protocol schema descriptions

Hi there, nice work on Cue it's a nifty format.

I'm the author of https://github.com/webrpc/webrpc which is a schema-driven framework for describing a microservice and then code-generating the server stubs and full client libraries -- similar to gRPC, but much simpler and designed for Web clients -- serialization is via JSON so the data structures are more flexible, and webrpc also supports HTTP1 and 2 transports.

In any case, as a part of webrpc, we created our own format for describing a service called RIDL (rpc interface design language), that looks like so: https://github.com/webrpc/webrpc/blob/master/_examples/hello-webrpc-ts/hello-api.ridl

I think cue is pretty cool and much more powerful and come be a viable replacement for RIDL. Certainly for the message types it would work, but I've been searching through the Cue docs and examples trying to find a syntax/form that could help me describe the function definitions and nothing turned up.

Any suggestions how to represent something like this with cue: https://github.com/webrpc/webrpc/blob/master/_examples/hello-webrpc-ts/hello-api.ridl#L33-L36 ?

thanks.

closed time in 19 days

pkieltyka

issue commentcuelang/cue

Cue for protocol schema descriptions

Using attributes as declarations is now supported. It is highly advisable to use CUE tokens in such attributes, so using @rpc(Ping(): (status: bool)) instead of @rpc(Ping() => (status: bool)), but other than that it all seems reasonable.

There is no functionality in the API yet to resolve tokens yet, but I could imagine adding that down the road. Closing this for now, but feel free to open again or create an new issue for followups on this.

pkieltyka

comment created time in 19 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 1ffc615f69a2c4e332c6e182af0e250965eaece9

cue: limit number of position errors Retrieving locations of possible errors does not do cycle checking. Limit number of positions to avoid getting a stack overflow. Fixes #269. Change-Id: Ibd297eeae64386e557a864577b141d2dc8c62dab Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4840 Reviewed-by: Marcel van Lohuizen <mpvl@google.com>

view details

push time in 19 days

issue closedcuelang/cue

stack overflow in no cycles.

type:: {
    x: 0
    y: 0

    if x == 0 { i: 0 }
    if y == 0 { j: 0 }
}

data: {
    a: type
    b: type

    b: x: a.x
    a: y: b.y
}

this cue code occurs runtime: goroutine stack exceeds 1000000000-byte limit. cue version is cue version 0.0.15 linux/amd64

closed time in 19 days

luuvish

push eventcuelang/cue

Marcel van Lohuizen

commit sha 0a6f7c9b8e0a75006b933f3fbadb8cdd8a31257c

cue: implement attribute declarations This only allows attributes in places that can clearly be considered to be part of the package fields. The spec has been adjusted accordingly. Issue #259 Change-Id: I3c8b65554096502577b48082c638c662eee98ac5 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4823 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 19 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 7bf9520ee30b5c73415594b7c29cb89e09ab8fa1

Update issue templates

view details

push time in 19 days

PR opened cuelang/cue

Update issue templates
+61 -0

0 comment

2 changed files

pr created time in 19 days

create barnchcuelang/cue

branch : mpvl-patch-1

created branch time in 19 days

issue commentcuelang/cue

Problem when generating from enum type of protobuf

Can you say how to reproduce the problem?

In general, enums are used in messages, where they are optional. So such messages should not be incomplete. If you mean evaluating the produced config, the real issue here is that the messages, enums etc. should all be definitions. Then this wouldn't be an issue.

In general, it seems that a best practice is for top-level definitions to not have default values. On top of that, all fields in proto3 are optional. But maybe it should generate defaults as prescribed by proto3 for all fields. This generally results in less nice schema, though, and in some cases carrying over this semantics is undesirable. It could be made an option perhaps.

ryoya-fujimoto

comment created time in 19 days

issue commentcuelang/cue

encoding/openapi: additionalProperties should be false for closed struct

Yeah, possibly. Their standard really should address these modes.

OpenAPI also allows additionalProperties: false, it is just the CRD that doesn't. I think in the case of OpenAPI, given its purpose, it highly dubious to support additionalProperties: false. But I see your point this is different for JSON Schema.

I think it should be an option, the question is what the default should be. For OpenAPI the default should be to not generate this. Ideally the default is the same for both, but arguably the default should be close for JSON Schema.

The right approach here, I think, is to port the Schema generation from the openapi package to the jsonschema package, make it proper JSON schema, and then see if we can express OpenAPI generation in terms of JSON schema generation.

Note that CRD put other restrictions on OpenAPI, including some normalizations, that are not strictly necessary in JSON Schema. I think the OpenAPI schema will execute the normalizations if possible.

proppy

comment created time in 21 days

issue commentcuelang/cue

encoding/openapi: additionalProperties should be false for closed struct

So my suspicions were correct: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#validation

CRD's put restrictions on the use of additionalProperties.

What would be a good forum for this?

I just asked Stefan Schimanski himself. :)

The reason for this is exactly as expected: to allow for extendible APIs one should not restrict the addition of fields. Clients can still complain about unknown fields, but the OpenAPI definition (for CRDs) is supposed to indicate all allowed values and thus for any proper API, additionalProperties cannot be set to false.

As to (a), I hope we can do something better than this. These kind of approaches tend to be not scalable, from a UX perspective. I can also imagine coming up with a single interpretation of closed structs that works for both case. My current stance on closedness in CUE is that closedness only applies to a particular version of an API, but should be ignored for incoming messages.

Anyway, in conclusion, the requested change would break a common use cases of OpenAPI: CRDs in K8s. A lot of thought went into this interpretation when it comes to proper APIs.

In other words, the interpretation of closedness in OpenAPI is just different from that of CUE. OpenAPI represents closedness regarding accepted messages, whereas CUE considers it in terms of current API version. So for now, it seems better to not add additionalProperties: false. Even if these interpretation prove false, the current mapping is legal: an OpenAPI schema generated from CUE should not reject values accepted by the corresponding CUE, but may accepted values rejected by the original CUE. So it is also the more conservative stance to take.

What is you particular use case for this feature? I could imagine making this an option. On the other hand, this seems to encourage bad API design. So this should only be added if there is a concrete need for it and with the proper note of caution.

proppy

comment created time in 22 days

issue commentcuelang/cue

How to set up per-environment configs

BTW, a complete different approach to solve your symlink issue is to import and embed your services into the different environments:

// production.cue
import "module.org/services"

services // embed

But that approach still doesn't work well if one wants to be more flexible in combining different inputs.

vikstrous

comment created time in 22 days

issue commentcuelang/cue

How to set up per-environment configs

There is one other approach that may help here: specify configuration parts itself on the command line. To improve analyzability, it is probably best if the allowed values are explicitly tagged. For instance,

var: domain: "prod" | "staging" | "test" @tag()

would then allow cue eval -t var.domain=prod. The tag attribute could be of the form @tag(name[,value]), where name is either empty, an alias or -, where the latter treats the possible values as boolean flags (value must be disjunction of strings). value would allow to further constrain the possible values. Values must be something that can be parsed with flags.

Only tags defined in a package itself would be considered: tags defined in imported packages are not.

var: domain: "prod" | "staging" | "test" @tag(env)

could allow cue eval -t env=prod and

var: domain: "prod" | "staging" | "test" @tag(-) // values must be unique

could allow cue eval -t prod

Advantages both less intrusive and more flexible than build tags. It feels more like CUE. Unlike build tags, it allows for injection of dynamic values on the command line.

The disadvantage is that this is starting to look like the non-hermetic injection of many other config langs. It is not changing the nature of the configuration, however, and having explicit tags, like build tags, makes intent explicit, instead of shoving it under a rug. I expect a similar kind of analysis to be possible as with build tags.

vikstrous

comment created time in 22 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha fe7a58a7e919c2bf6ab373029000f4c7d9992f3a

pkg/list: pick default before flattening If a default isn't choses, it is not clear what to flatten and the result will be unexpected when a default is chosen later. In general arguments to builtins should be treated as manifested. Fixes #268 Change-Id: I3f7b917b97689d0b0911d569c666ff00383cb46e Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4822 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 22 days

issue closedcuelang/cue

pkg/list: list.Flatten fails on non-final value

This cue code:

import "list"
Items :: [... string] | *[]
x: list.FlattenN([Items], -1)

produces:

{
    "x": [
        []
    ]
}

not the expected:

{
    "x": []
}

It seems that the flatten code isn't treating Items as a list.

closed time in 22 days

rogpeppe

push eventcuelang/cue

Marcel van Lohuizen

commit sha a9b38dbd2ad6c2769eab462b4bcdcd5b02a83dae

pkg/encoding/yaml: validate using instance check Assume that the YAML value is final. This seems the expected behavior in most cases. ValidatePartial now has the original meaning. Fixes #266 Change-Id: I7285bc5327ce661c720c9cd2254dc9fe8f9bcdc3 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4821 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 22 days

issue closedcuelang/cue

Required fields seem to not work

Hey 👋

We are trying to use CUE as a schema for our configuration. What is not obvious to me is how I can make field required in terms that it needs to be provided in YAML as currently none of an examples seems to work for me :(

// dim.cue
import "encoding/yaml"

// Phrases defines a schema for a valid phrase.
Phrases :: {
    phrases: { <_>: Phrase }

    Phrase :: {
        lang:         LanguageTag
        text:         !=""
        attribution?: !="" // must be non-empty when specified

    }
    LanguageTag :: =~"^[a-zA-Z0-9-_]{2,}$"
}

// phrases is a YAML string with a field phrases that is a map of Phrase
// objects.
phrases: yaml.Validate(Phrases)

phrases: """
    phrases:
      # A quote from Mark Twain.
      quote1:
        lang: en
        attribution: Mark Twain

      # A Norwegian proverb.
      proverb:
        lang: no
        text: Stemmen som sier at du ikke klarer det, lyver.
    """

In above example if we omit text nothing happens and requirement for text being not empty is ignored, I feel that I am missing something more obvious in this scenario.

Thanks for help !

closed time in 22 days

melkorm

issue commentcuelang/cue

Required fields seem to not work

I've added a replacement for the Subsumes (now Subsume) that a) returns an error with locations instead of a boolean in case of failure and b) allows options to specify whether a value should be treated as "final" or a "schema". The yaml.Validate then can use the final subsumbtion for checking, assuming that that is what people typically want. A ValidatePartial can then mean the original.

melkorm

comment created time in 22 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 4dd963004774abf5a92661c7647b0426bcfc2e01

doc/ref/spec: attribute changes - support attributes for structs and packages - relax unification rules for field attributes In all cases, the presence of attributes can never fail unification in the new definition. It is now fully up to the consumer how to interpret duplicates. Struct and package attributes are handy in several locations, as it turns out. For instance, CUE has a shared name space for definitions and values. In JSON schema, for instance, this is not the case. so a CUE mapping will have to be structured differently. Recording this mapping in field attributes is awkward. See also Issue #259 Issue #190 Change-Id: Ia7b79ca6165faa5eea11fef3cc4c456054632233 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4602 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha c7c70a67f19eb75b91ffbff6c288398d593d4d6b

cue: add Subsume to replace Subsumes - API allows distinction between Final and non-Final - return error Change-Id: I98b86fee753f18e620d4f17e6887decdb66d5b08 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4820 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in 22 days

push eventcuelang/cue

Marcel van Lohuizen

commit sha 47d9870fc3de9f719a2984a6dd6257dc1603522a

encoding/jsonschema: expose API of JSON Schema decoder Change-Id: I191d7bc2394486fa63050fca6721f65aa0589b22 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4760 Reviewed-by: Antoine Pelisse <apelisse@google.com> Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Koichi Shiraishi

commit sha 2e67318867329c1b6806811fb63e960cf17daac4

github: enable run goreleaser automatically when bump new tag Change-Id: Ieedeb07dcacf8ff7e6ae58a86c7072af0caf3f78 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4781 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Koichi Shiraishi

commit sha 0198c89de6d6b9b1bcce6f33db52400852ee28ab

module: update google/go-cmp to v0.4.0 Currently, test is failed on go devel (at least 641e61db57) because will run checkptr when go test and which is caused by go-cmp package. It has been fixed on https://github.com/google/go-cmp/pull/169, Update go-cmp package to latest release. test result: === RUN TestLiterals/0/"0" fatal error: checkptr: unsafe pointer arithmetic run: $ go get -u -d github.com/google/go-cmp@latest $ go mod tidy Change-Id: I7881e6c08fa3edb17b10b8b6f5a5e699211a9299 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4641 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

issue commentcuelang/cue

encoding/openapi: additionalProperties should be false for closed struct

Even though you're technically right, this is a somewhat tricky one. The correct definition depends a bit on how an API definition is used.

For instance, by definition, Protobuf are "open": if an application receives a message that has fields not defined by the current proto, the spec says to ignore these fields. However, code generated from protobuf definitions will fail if a non-existing fields are used and an application is not. What you see here is two modes of use: within a single application, one wants a single definition to be consistent. Even if the definition says to ignore unknown fields for outside messages, configuring for a known version, one still wants to catch typos. There are basically two modes of usage.

For this reason, proto to CUE conversion should keep a CUE definition closed. Received messages should be mapped to a CUE type using something akin to a type cast (unify ignoring closedness then eliminate unknown fields).

For the same reason, mapping CUE to OpenAPI may want to include a conversion from open to closed.

Anyway, running this by some of the users of this to find out their interpretation. I think it is reasonable to support this, but the question is whether this should be an option of some form.

proppy

comment created time in a month

issue commentcuelang/cue

Required fields seem to not work

@melkorm: the problem here is naming and lack of options in this API. Validate can mean many things. In this case it checks whether it unifies, so whether it is consistent with the given schema. This mode of checking is useful when one has fragments of YAML that are later composed into a larger piece. This is how CUE works and this has been the default mode of validation. It is also useful for validating fragments in systems that allow YAML composition, like Kustomize.

For YAML and JSON itself, as it turns out (and by hindsight obvious), one often wants to check whether something is an instance of a schema. It seems that that is what you are expecting here and why it seems it doesn't work.

More precisely, you want to validate that something is an instance, ignoring optional fields. Part of the reason that some of this functionality is not exposed is that there are actually many possible ways to validate. But it seems that unification and subsumption (instance of) ignoring optional fields are the most common modes.

Both are implemented, it is mostly a matter of finding the right API and naming. A few quick ideas:

  1. add a new function for validating the instance of relation: (e.g. ValidateSchema, Schema, IsA.)

Not backwards compatible: 2. Change Validate to be instance of, and introduce ValidatePartial for the current meaning 3. Change Validate to taken another option (probably a struct) allowing to configure behavior

I like option 2. It is backwards incompatible, but may fix common problems. I think the naming is clear, and will naturally guide people to the right pick without having to learn about the differences between unification and subsumption. (If it breaks, the documentation of the function can guide towards the use of ValidatePartial, if that is intended.

We could still later introduce a third variant, or add a variadic arg to Validate, if we were to extend the language that way, that would allow more configurable validation.

Also @zellyn

melkorm

comment created time in a month

issue commentcuelang/cue

cmd/cue: figure out most useful printing modes for command line

I'll consider the cue def mode. We were thinking of selecting output modes with flags or positional tags, but this will be so common, it makes sense to at least consider something along these lines.

An alternative is to select different output modes in the output flag, such as cue eval . --out schema

Yet another alternative is to have eval evaluate schema, and let export output data. The default for export could then be CUE instead of data. But this is akin to your suggestion, just with different names.

mpvl

comment created time in a month

push eventcuelang/cue

Marcel van Lohuizen

commit sha 2d8560de740816f87a33c6031fe239dcc2577b8a

pkg/tool: update documentation and remove $before $before is redundant and seems like it may cause limitations down the road. Removed as a precaution. Documentation has been updated to reflect current features. Closes #223. Note that environment variables will now be implemented as `tool/env` and as an option to `tool/exec.Run`. Flags will likely be a task type end be refereneable as, say, `tool/flags.Set`. Change-Id: Ic87766b6af2e546c25b30ada3f8a75e3c796b70d Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4740 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

issue closedcuelang/cue

Define schema for custom command

We have following schema in pkg/tool/tool.cue

package tool

// A Command specifies a user-defined command.
Command: {
	//
	// Example:
	//     mycmd [-n] names
	usage?: string

	// short is short description of what the command does.
	short?: string

	// long is a longer description that spans multiple lines and
	// likely contain examples of usage of the command.
	long?: string

	// TODO: define flags and environment variables.

	// tasks specifies the list of things to do to run command. Tasks are
	// typically underspecified and completed by the particular internal
	// handler that is running them. Task de
	tasks <name>: Task
}

// A Task defines a step in the execution of a command.
Task: {
	// kind indicates the operation to run. It must be of the form
	// packagePath.Operation.
	kind: =~#"\."#
}

And following schema in cmd/cue/cmd/cmd.go

command: [Name=string]: { // from tool.Command
    // usage gives a short usage pattern of the command.
    // Example:
    //    fmt [-n] [-x] [packages]
    usage?: Name | string

    // short gives a brief on-line description of the command.
    // Example:
    //    reformat package sources
    short?: string

    // long gives a detailed description of the command, including a
    // description of flags usage and examples.
    long?: string

    // A task defines a single action to be run as part of this command.
    // Each task can have inputs and outputs, depending on the type
    // task. The outputs are initially unspecified, but are filled out
    // by the tooling
    task: [string]: { // from "tool".Task
        // supported fields depend on type
    }

    VarValue = string | bool | int | float | [...string|int|float]

    // var declares values that can be set by command line flags or
    // environment variables.
    //
    // Example:
    //   // environment to run in
    //   var env: "test" | "prod"
    // The tool would print documentation of this flag as:
    //   Flags:
    //      --env string    environment to run in: test(default) or prod
    var: [string]: VarValue

    // flag defines a command line flag.
    //
    // Example:
    //   var env: "test" | "prod"
    //
    //   // augment the flag information for var
    //   flag env: {
    //       shortFlag:   "e"
    //       description: "environment to run in"
    //   }
    //
    // The tool would print documentation of this flag as:
    //   Flags:
    //     -e, --env string    environment to run in: test(default), staging, or prod
    //
    flag [Name=_]: { // from "tool".Flag
        // value defines the possible values for this flag.
        // The default is string. Users can define default values by
        // using disjunctions.
        value: *env[Name].value | VarValue

        // name, if set, allows var to be set with the command-line flag
        // of the given name. null disables the command line flag.
        name?: *Name | string

        // short defines an abbreviated version of the flag.
        // Disabled by default.
        short?: string
    }

    // populate flag with the default values for
    for k, v in var {
        flag: { "\(k)": { value: v } | null  }
    }

    // env defines environment variables. It is populated with values
    // for var.
    //
    // To specify a var without an equivalent environment variable,
    // either specify it as a flag directly or disable the equally
    // named env entry explicitly:
    //
    //     var foo: string
    //     env foo: null  // don't use environment variables for foo
    //
    env: [Name=_]: {
        // name defines the environment variable that sets this flag.
        name?: *"CUE_VAR_" + strings.Upper(Name) | string

        // The value retrieved from the environment variable or null
        // if not set.
        value?: string | bytes
    }
    env: {
        for k, v in var {
            "\(k)": { value: v } | null
        }
    }
}

Since we're about to support flags and environment variables, maybe we can finalize the schema definition for command now.

closed time in a month

adieu

issue commentcuelang/cue

Add functions from path/filepath

There has been an increasing desire to evaluate tool files as data as well. This complicates simply adding such builtins. As their output depends on the environment, they are not hermetic and tools like trim are useless or even dangerous.

One way around this would be for these builtins to return some stub (a new internal type or so) that would always return an "incomplete" status by default, but that would become "activated" when running in tool mode.

Other than that, I think pkg/tool/file/filepath is a fine location.

tredoe

comment created time in a month

issue commentcuelang/cue

convertRec and null/nil values

Yes, that makes sense. It should probably be *null | _, and definitely not null | _.

It seems you have the change already, so feel free to send a PR. Thanks!

bastianccm

comment created time in a month

issue commentcuelang/cue

Validate Multiple YAML Types through Configuration

For completeness, another direction one could go in to, based on @rogpeppe suggestion, is that files of a particular kind within a directory are accessible through a package. This would allow one to create a derivative package where these files are assigned types.

Very roughly:

import (
    json "path/to/dir:$json" // or some other syntax for "special json import"
    "path/to/schema"
)

json

[string]: schema.Foo

I don't think I'm doing this justice here, but there are some distinct benefits to this approach. Most notably, one would be able to see just from the file imports and directory layouts what depends on what.

Yet another approach is to use the emerging standard (from JSON schema) to annotate JSON structs with "$schema": "https://example.org/foo.json" to define which schema they depend on. This could directly map to the directory layout in cue.mod, which then may contain a schema based on JSON schema, CUE, or a combination. cue get could be made to automatically pull these schema in if they are not defined.

A sort of hybrid approach could be that one writes a .cue file in a directory with JSON files with a special package declaration, say package $json the contents of which will automatically unify with all JSON files.

rawkode

comment created time in a month

push eventcuelang/cue

Marcel van Lohuizen

commit sha 7a02899443e7012871f1f7545b06643cb5051736

cmd/cue/cmd: fail in case flag evaluation fails Fixes #248 Change-Id: Ifb39450af2b99aba41e37a17822780249669c0c0 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4725 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

issue closedcuelang/cue

eval to undefined should be able to exit with a non-zero error code

I have a script that interacts with the cue CLI. It does an eval in several places based on user input. If the user input is wrong, cue will return an undefined value.

 ./output/bin/cue eval foo.cue  -e foo
_|_ // reference "foo" not found

This output is probably helpful for a user interaction. From a scripting interaction it is very annoying. The backwards compatible way to improve scripting is to exit with a non-zero code. If you really want to stay backwards compatible, add a -e option that turns on the exit code (jq actually does exactly this).

closed time in a month

gregwebs

issue commentcuelang/cue

eval to undefined should be able to exit with a non-zero error code

I am willing to take that risk. I think any reasonable person would expect a non-zero code here.

I looked at the -e flag of jq and it can be useful in some cases, though.

gregwebs

comment created time in a month

issue commentcuelang/cue

eval to undefined should be able to exit with a non-zero error code

I'm fine with returning a non-zero exit code and am surprised it doesn't.

What would be the benefit of not returning a non-zero exit code there? And what are the reasons jq would return a zero exit code in case of an error?

Thanks!

gregwebs

comment created time in a month

push eventcuelang/cue

Koichi Shiraishi

commit sha 83fa8f48d41371be7468d4a7a0ea61905c0b6f6e

cue: add '-local cuelang.org/go' flag for buildins.go Same as CL 4501, formats buildins.go file with -local flag. Change-Id: I089d57fe87787a5060c57118d4b48ee365129475 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4642 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Koichi Shiraishi

commit sha a96b3bbcec3b30e51ffc5fe42881450da1c08590

cue/errors: remove unnecessary first slice length on list.Reset() The convention way of reset any slice is to set the last slice length only. Change-Id: I3847c764deac32b39fe81e7e7fb0c76da0648293 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4640 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

push eventcuelang/cue

Marcel van Lohuizen

commit sha 3b17f6ac913c24d4c0da53f4d16f678b00006c67

cmd/cue/cmd: err on space-separated syntax It is still supported, but only to accomodate cue fmt. Change-Id: Iac26d28b58ebbe87275ea531ba1d712dceda2edf Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4723 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

push eventcuelang/cue

Marcel van Lohuizen

commit sha 2b93e1150c27ec2fdb189818b9757edadd28fc53

cue/ast/astutil: catch cycle for label expressions If such labels need to would be applied to the field referenced to. In some cases this should actually be legal, according to the spec, but we will make this a compilation error for now until we fix the evaluator. Closes #251 Change-Id: I167a87cb1866fc2991abe29a05c53356cf23805b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4720 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 0797e46cf394a41085a9afb51396ba4628edbfcf

encoding/protobuf: don't rely on verbatim Ident formatting Parse the expressions into proper CUE before formatting. Change-Id: I66fdf247c7f5d949aa76aa46906b36656c502f25 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4721 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha 78c24c56a403677dfbff59559ae615cad6f5214a

cue/format: only format valid identifiers Change-Id: Ic71bdacc4168671b34cdf61f0713b9012f0a0b38 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4722 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

issue closedcuelang/cue

BUG: stackoverflow when refrencing definition or field as optional field

cue version 0227ac0236326923794f2ed119b57bcc24d938ae

refrencing a field or a definition produces a stackoverflow when used in a emit

bug.cue:

{
  [Def]: _
}

Def :: _
/tmp » cue eval bug.cue
runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

runtime stack:
runtime.throw(0xc2a0db, 0xe)
        /usr/local/go/src/runtime/panic.go:617 +0x72
runtime.newstack()
        /usr/local/go/src/runtime/stack.go:1041 +0x6f0
runtime.morestack()
        /usr/local/go/src/runtime/asm_amd64.s:429 +0x8f

goroutine 1 [running]:
runtime.heapBitsSetType(0xc00878f4a0, 0xa0, 0xa0, 0xc04ae0)
        /usr/local/go/src/runtime/mbitmap.go:938 +0xa56 fp=0xc024000300 sp=0xc0240002f8 pc=0x417b56
runtime.mallocgc(0xa0, 0xc04ae0, 0x1, 0x0)
        /usr/local/go/src/runtime/malloc.go:969 +0x51c fp=0xc0240003a0 sp=0xc024000300 pc=0x40d89c
runtime.newobject(0xc04ae0, 0x0)
        /usr/local/go/src/runtime/malloc.go:1068 +0x38 fp=0xc0240003d0 sp=0xc0240003a0 pc=0x40def8
cuelang.org/go/cue.(*structLit).at(0xc000243110, 0xc00021d1e0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1115 +0xdb fp=0xc024000500 sp=0xc0240003d0 pc=0x78abeb
cuelang.org/go/cue.(*structLit).iterAt(0xc000243110, 0xc00021d1e0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1042 +0x123 fp=0xc024000570 sp=0xc024000500 pc=0x78aaa3
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1018 +0x1a0 fp=0xc0240006a0 sp=0xc024000570 pc=0x78a6b0
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc0240007b0 sp=0xc0240006a0 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878afc0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024000888 sp=0xc0240007b0 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc0240009b8 sp=0xc024000888 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024000ac8 sp=0xc0240009b8 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878af90, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024000ba0 sp=0xc024000ac8 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024000cd0 sp=0xc024000ba0 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024000de0 sp=0xc024000cd0 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878af60, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024000eb8 sp=0xc024000de0 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024000fe8 sp=0xc024000eb8 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc0240010f8 sp=0xc024000fe8 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878af30, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240011d0 sp=0xc0240010f8 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024001300 sp=0xc0240011d0 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024001410 sp=0xc024001300 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878af00, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240014e8 sp=0xc024001410 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024001618 sp=0xc0240014e8 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024001728 sp=0xc024001618 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aed0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024001800 sp=0xc024001728 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024001930 sp=0xc024001800 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024001a40 sp=0xc024001930 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aea0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024001b18 sp=0xc024001a40 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024001c48 sp=0xc024001b18 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024001d58 sp=0xc024001c48 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ae70, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024001e30 sp=0xc024001d58 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024001f60 sp=0xc024001e30 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024002070 sp=0xc024001f60 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ae40, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024002148 sp=0xc024002070 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024002278 sp=0xc024002148 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024002388 sp=0xc024002278 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ae10, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024002460 sp=0xc024002388 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024002590 sp=0xc024002460 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc0240026a0 sp=0xc024002590 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ade0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024002778 sp=0xc0240026a0 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc0240028a8 sp=0xc024002778 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc0240029b8 sp=0xc0240028a8 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878adb0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024002a90 sp=0xc0240029b8 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024002bc0 sp=0xc024002a90 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024002cd0 sp=0xc024002bc0 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ad80, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024002da8 sp=0xc024002cd0 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024002ed8 sp=0xc024002da8 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024002fe8 sp=0xc024002ed8 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ad50, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240030c0 sp=0xc024002fe8 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc0240031f0 sp=0xc0240030c0 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024003300 sp=0xc0240031f0 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ad20, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240033d8 sp=0xc024003300 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024003508 sp=0xc0240033d8 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024003618 sp=0xc024003508 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878acf0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240036f0 sp=0xc024003618 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024003820 sp=0xc0240036f0 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024003930 sp=0xc024003820 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878acc0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024003a08 sp=0xc024003930 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024003b38 sp=0xc024003a08 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024003c48 sp=0xc024003b38 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ac90, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024003d20 sp=0xc024003c48 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024003e50 sp=0xc024003d20 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024003f60 sp=0xc024003e50 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ac60, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024004038 sp=0xc024003f60 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024004168 sp=0xc024004038 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024004278 sp=0xc024004168 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ac30, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024004350 sp=0xc024004278 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024004480 sp=0xc024004350 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024004590 sp=0xc024004480 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ac00, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024004668 sp=0xc024004590 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024004798 sp=0xc024004668 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc0240048a8 sp=0xc024004798 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878abd0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024004980 sp=0xc0240048a8 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024004ab0 sp=0xc024004980 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024004bc0 sp=0xc024004ab0 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aba0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024004c98 sp=0xc024004bc0 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024004dc8 sp=0xc024004c98 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024004ed8 sp=0xc024004dc8 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ab70, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024004fb0 sp=0xc024004ed8 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc0240050e0 sp=0xc024004fb0 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc0240051f0 sp=0xc0240050e0 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ab40, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240052c8 sp=0xc0240051f0 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc0240053f8 sp=0xc0240052c8 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024005508 sp=0xc0240053f8 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878ab10, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240055e0 sp=0xc024005508 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024005710 sp=0xc0240055e0 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024005820 sp=0xc024005710 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aae0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc0240058f8 sp=0xc024005820 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024005a28 sp=0xc0240058f8 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024005b38 sp=0xc024005a28 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aab0, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024005c10 sp=0xc024005b38 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024005d40 sp=0xc024005c10 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024005e50 sp=0xc024005d40 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aa80, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024005f28 sp=0xc024005e50 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024006058 sp=0xc024005f28 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024006168 sp=0xc024006058 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aa50, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024006240 sp=0xc024006168 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024006370 sp=0xc024006240 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024006480 sp=0xc024006370 pc=0x745671
cuelang.org/go/cue.(*optionals).constraint(0xc00026d3b0, 0xc00021d1e0, 0xd4b4a0, 0xc00878aa20, 0x0, 0x0, 0xd4ada0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:894 +0x226 fp=0xc024006558 sp=0xc024006480 pc=0x789786
cuelang.org/go/cue.(*structLit).lookup(0xc000243110, 0xc00021d1e0, 0xc0000002c2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/value.go:1025 +0x2b5 fp=0xc024006688 sp=0xc024006558 pc=0x78a7c5
cuelang.org/go/cue.(*selectorExpr).evalPartial(0xc00026d350, 0xc00021d1e0, 0x0, 0x0)
        /home/username/.golang/src/cuelang.org/go/cue/eval.go:127 +0x1e1 fp=0xc024006798 sp=0xc024006688 pc=0x745671
...additional frames elided...

closed time in a month

rudolph9

push eventcuelang/cue

Marcel van Lohuizen

commit sha 1288f89f2f6ffc55bd10155e3aaf28feb61077e7

cue/load: expose error types Change-Id: I6910aa23d385182c5bc7b83d617289c783b73873 Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4662 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

push eventcuelang/cue

Marcel van Lohuizen

commit sha 00757a9f3cbd5fe86afe797dbb4b6fec7296e458

cmd/cue/cmd: fix crash Fixes #261 Change-Id: If014a03a5c000b4e8ed90956d76664238e59f60d Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4701 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

issue closedcuelang/cue

empty string keys cause panic in `cue vet`

~/tmp mkdir cuetest
~/tmp cd cuetest/
~/tmp/cuetest echo '{"":42}' > test.yaml
~/tmp/cuetest echo 'foo?: int' > check.cue
~/tmp/cuetest cue vet test.yaml check.cue 
invalid field name: :
    ./test.yaml:1:3
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x136e2a6]

goroutine 1 [running]:
cuelang.org/go/cmd/cue/cmd.recoverError(0xc000225eb0)
	/Users/mpvl/dev/release/cue/cmd/cue/cmd/root.go:211 +0xa3
panic(0x174a680, 0x1dee000)
	/usr/local/go/src/runtime/panic.go:679 +0x1b2
cuelang.org/go/cue.(*Instance).Value(0x0, 0x1faf3c0, 0xc00025aaf0)
	/Users/mpvl/dev/release/cue/cue/instance.go:190 +0x26
cuelang.org/go/cmd/cue/cmd.vetFiles(0xc00020f9e0, 0xc000101900, 0xc0001e9f60, 0x1, 0x1)
	/Users/mpvl/dev/release/cue/cmd/cue/cmd/vet.go:181 +0x593
cuelang.org/go/cmd/cue/cmd.doVet(0xc00020f9e0, 0xc00020fe40, 0x2, 0x2, 0x0, 0x0)
	/Users/mpvl/dev/release/cue/cmd/cue/cmd/vet.go:99 +0x64b
cuelang.org/go/cmd/cue/cmd.mkRunE.func1(0xc000264500, 0xc00020fe40, 0x2, 0x2, 0x0, 0x0)
	/Users/mpvl/dev/release/cue/cmd/cue/cmd/root.go:46 +0x5f
github.com/spf13/cobra.(*Command).execute(0xc000264500, 0xc00020fde0, 0x2, 0x2, 0xc000264500, 0xc00020fde0)
	/Users/mpvl/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:762 +0x460
github.com/spf13/cobra.(*Command).ExecuteC(0xc00025e500, 0x0, 0xc00020fc80, 0x0)
	/Users/mpvl/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:852 +0x2ea
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/mpvl/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:800
cuelang.org/go/cmd/cue/cmd.(*Command).Run(0xc00020f9e0, 0x1930a40, 0xc000034130, 0x0, 0x0)
	/Users/mpvl/dev/release/cue/cmd/cue/cmd/root.go:196 +0x75
cuelang.org/go/cmd/cue/cmd.mainErr(0x1930a40, 0xc000034130, 0xc000030110, 0x3, 0x3, 0x1d9b540, 0xc000062750)
	/Users/mpvl/dev/release/cue/cmd/cue/cmd/root.go:131 +0x74
cuelang.org/go/cmd/cue/cmd.Main(0xc0000400b8)
	/Users/mpvl/dev/release/cue/cmd/cue/cmd/root.go:116 +0x84
main.main()
	/Users/mpvl/dev/release/cue/cmd/cue/main.go:24 +0x22

closed time in a month

zellyn

push eventcuelang/cue

Marcel van Lohuizen

commit sha 6320089ce9c4d85319faed1247374fb4b0365dfd

doc/tutorial/basics: change title of section Change-Id: Id79a09bd9a518a2bf6b08a2f0dd26c3fc2972d1f Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4700 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

Marcel van Lohuizen

commit sha f6f7791ce4afee6d42d89b24f00b1ac16d31b20e

cue/load: remove unnecessary colon check Change-Id: I19e5c1ecbfb4408220ce7fcd18880e5d8f60e90b Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4661 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

push eventcuelang/cue

Marcel van Lohuizen

commit sha 72f8e8ae972d730188d7a4b0701424e9170bf6f3

pkg/tool/exec: allow passing env vars in exec.Run Closes #260 https://github.com/cuelang/cue/pull/260 GitOrigin-RevId: 25e566f00afa109e7d6ef1762a18b0f466e819d9 Change-Id: I80de4b7d278abf87323b516e564125f582c97e9a Closes #264 https://github.com/cuelang/cue/pull/264 GitOrigin-RevId: 097c5a03b5665e1677e91c1f64070f28787b0658 Change-Id: I937463c5fdb6b562b457fa550d2840705ebee91d Reviewed-on: https://cue-review.googlesource.com/c/cue/+/4680 Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>

view details

push time in a month

more