We should probably move these into the central interfaces package so
that these can be used from multiple places. They don't have any
dependencies, and it doesn't make sense to have the solver code mixed in
to the same package. Overall the interface being implemented here could
probably be improved, but that's a project for another day.
This is a new path manipulation library that is designed to be safer
than using simple strings for everything. It is more work to use, but it
can help you keep track of the different path types.
It has been sitting unused in a git branch for too long, and I figured
it should see the light of day in case someone wants to start using it.
In case a programmer makes a mistake and passes in a function using the
simple function API without a type or even without the entire value,
we'll now return a sensible error message and panic in init() instead of
requiring a test to catch this alone.
It would be great to fix some rare races or debug what's wrong in CI,
but for now let's get rid of these fails so that we can get better data
for when we break something more serious. We'll need to revisit all of
this for sure.
Seems Github actions breaks or unsets this, leading to the errors:
tput: No value for $TERM and no -T specified
seq: missing operand
Try 'seq --help' for more information.
Hopefully this makes things a bit more robust.
The original string interpolation was based on hil which didn't allow
proper escaping, since they used a different escape pattern. Secondly,
the golang Unquote function didn't deal with the variable substitution,
which meant it had to be performed in a second step.
Most importantly, because we did this partial job in Unquote (the fact
that is strips the leading and trailing quotes tricked me into thinking
I was done with interpolation!) it was impossible to remedy the
remaining parts in a second pass with hil. Both operations needs to be
done in a single step. This is logical when you aren't tunnel visioned.
This patch replaces both of these so that string interpolation works
properly. This removes the ability to allow inline function calls in a
string, however this was an incidental feature, and it's not clear that
having it is a good idea. It also requires you wrap the var name with
curly braces. (They are not optional.)
This comes with a load of tests, but I think I got some of it wrong,
since I'm quite new at ragel. If you find something, please say so =D In
any case, this is much better than the original hil implementation, and
easy for a new contributor to patch to make the necessary fixes.
Improves readability of CI test output and hides away the complexity
when in most cases it is not required. Retain fold behaviour for both
Travis and GitHub Actions in case both are used in any capacity.
Signed-off-by: Joe Groocock <me@frebib.net>
Ubuntu-latest in GitHub Actions provides linuxbrew, so the tests install
both the native Debian dependency packages, and also the linuxbrew
variants which is slower and entirely redundant.
Signed-off-by: Joe Groocock <me@frebib.net>
In bash `-n` is `non zero length` which is the opposite of `-z` meaning
`zero length`. `-n` is semantically identical to `! -z` but `-n`.
Signed-off-by: Joe Groocock <me@frebib.net>
in_ci checks for environment variables set by a selection of CI systems
and returns true if the test appears to be running in CI. Additionally
it can test for specific CI systems, and returns true if the CI system
is listed.
Deduplicate existing environment checks for Travis and Jenkins.
Signed-off-by: Joe Groocock <me@frebib.net>
These dependencies are maintained because the upstream repos bundle
vendor directories into the repos, which cause namespacing issues during
build. Git submodules don't strip the vendor directory whereas most
vendoring tools would.
Signed-off-by: Joe Groocock <me@frebib.net>
This allows dropping the pinned grpc-prometheus and grpc-gateway
libraries as git master works fine for now.
Signed-off-by: Joe Groocock <me@frebib.net>
The vumeter example was written quickly and without much care. This
fixes a possible race (panic) and also removes the busy loop that wastes
CPU while we're waiting for the first value to come in.
Struct field names now correctly map based on their `lang` tags in Go
structs, so this example now works as originally intended.
Signed-off-by: Joe Groocock <me@frebib.net>
Converting a reflect.Type of KindStruct did not respect the `lang` tag
on struct fields incidating how fields from mcl structs should be mapped
even though resource field names did. This patch should allow structs
with mapped fields to be respected.
Signed-off-by: Joe Groocock <me@frebib.net>
Replace existing field-mapping code with calls to types.Into() to
reflect the mcl data into the Go resource struct with finer granularity
and accuracy, and less reliance on the magic reflect.Set() function.
One major advantage over reflect.Value.Set() is Into() allows tailoring
the data that is set, specifically when coercing mcl struct values into
Golang struct values, the fields can be appropriately mapped based on
the lang tag on the struct field. With reflect.Value.Set() this was not
at all possible as there was a contradiction of logic given the
following rules:
- mcl struct fields must have lowercase names
- Golang struct fields with lowercase names are unexported
- Golang reflection does not allow modifying unexported fields
Prior to this change, it was impossible to map an mcl inline struct in a
resource to the matched Golang counterpart, even if the lang tag was
present on the struct field. This can be demonstrated with the following
trivial example:
test "name" {
key => struct{
name => "hello",
},
}
and the accompanying Golang resource definition:
type TestRes struct {
traits.Base
traits.Edgeable
Key struct {
Name string `lang:"name"`
} `lang:"key"`
}
Due to the mismatch in field names in the embedded struct, the type
unifier failed and refused to match mcl 'name' to Go 'Name' due to the
missing mapping logic.
Signed-off-by: Joe Groocock <me@frebib.net>
Into() mutates a given reflect.Value and sets the data represented by
the types.Value into the storage represented by the reflect.Value.
Into() is the opposite to ValueOf() which converts reflect.Value into
types.Value, and in theory they should be (almost) bijective with some
edge case exceptions where the conversion is lossy.
Simply, it replaces reflect.Value.Set() in the broad case, giving finer
control of how the reflect.Value is modified and how the data is set.
types.Value.Value() is now also a redundant function that achieves the
same outcome as Into(), but with less type specificity.
Signed-off-by: Joe Groocock <me@frebib.net>
This constant value is strongly tied to the language, and little to do
with the engine. Move the definition into the lang/types package to
prevent circular imports between lang/types and engine/util.
Signed-off-by: Joe Groocock <me@frebib.net>
Replace use of reflect.Value.Len() with NumField() which is intended to
return the number of fields in reflected Struct value.
Len should only be used for Array, Chan, Map, Slice and String types.
Add some trivial sanity check tests for ValueOf() for the simple and
complex container types.
Signed-off-by: Joe Groocock <me@frebib.net>
While the code comment says to check if go vet command is present,
it actually tests if go vet command returns properly.
This is a problem if go vet is _not_ returning 0 due to a
failure while go vet is present: it will try to install the
legacy go vet.
This fixes it by removing this block of code completely,
as we assume a golang version which contains it anyway.
Contradictory to expectations, `mgmt run lang metadata.yaml` would
produce an error similar to the following, which is likely unexpected
from the user perspective:
2020-11-24 12:24:08.330968 I | cli: lang: lexing/parsing...
2020-11-24 12:24:08.331153 I | run: error: cli parse error: could not generate AST: parser: `syntax error: unexpected DOT` @1:1
Produce a user-friendly warning instead, hinting with the supported
usage:
2020-11-24 13:15:01.686659 I | run: error: cli parse error: could not activate an input parser: unexpected raw code 'metadata.yaml'. Did you mean './metadata.yaml'?
Signed-off-by: Joe Groocock <me@frebib.net>
