This can construct non-overlapping nested attribute sets (i.e. `{ a.b
= 1; b.c = 2; }`, but not `{ a.b = 1; a.c = 2; }`).
In order to do the latter, it's necessary to gain the ability to
manipulate the in-progress attribute set construction. There's
multiple different options for this ...
Change-Id: If1a762a720b175e8eb4216cbf96a7434d22640fb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6106
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
There are some notions of equality (due to e.g. different backing
variants for types, or Nix particularities) that don't work correctly
when deriving PartialEq.
Change-Id: Ide83ae67d051cc0b3ca89cefb283f17d0207acce
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6105
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This is required for constructing nested attribute sets at runtime.
There'll be quite a lot of optimisation potential with this solution
eventually, if it should turn out to be a bottleneck.
This introduces a conceptual change, in that the `Value` enum is now
an enum representing "all runtime values" instead of "all Nix language
types". This makes sense in general, as this type will also contain
Chunk representations etc. which are not exposed to users.
Change-Id: Ic5f72b2a0965b146c6a451efad34c6a81ca1aad8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6103
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
For name/value pairs (which occur extremely often in Nix and make up a
significant chunk of the runtime cost of evaluating nixpkgs) we
substitute an optimised representation.
For now this will only be used if the name/value pair keys were
specified as literal identifiers or strings (i.e. if chunks are
encountered as keys they are not forced and a normal attribute set
backed by a map will be constructed).
Change-Id: Ic79746c323e627528bd58b1a6024ee8d0aff7858
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6102
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Users may construct a pair that falls into the name/value optimisation
but where `name` is not actually a string, as from the language
perspective there is nothing special about this attribute set.
We also can not conditionally apply this by forcing the key at this
point, as this would change the language semantics.
Therefore, the name in the optimised representation is also carried as
`Value`.
Change-Id: I5be8a4c98ba19ebdfb7203a929f714a04492512e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6101
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This adds a new instruction which assembles an interpolated string
from a specified number of fragments, which are already going to be
located on the stack in the right position.
This will raise a type error if any of the fragments do not evaluate
to a string.
Change-Id: I5756248fa3e9fcc3d063c14db40b332f7e20a588
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6098
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This sets up the scaffolding for compiling interpolation, but those
instructions do not yet exist.
Change-Id: Ife41bbbf432d9661abe566c92437409dd0da44e7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6097
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
There might be more logic in the future to encapsulate different
backing implementations of lists as well.
Change-Id: Ib7064fab48bf88b0c8913b0ecfa2108177c7c9fd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6093
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Autosubmit: tazjin <tazjin@tvl.su>
Implements attribute set literals without nesting. Technically this
already supports dynamic key fragments (evaluating to strings), though
the only way to create these (interpolation) is not yet implemented.
However, creating simple attribute sets like `{ }`, or `{ a = 15; }`
or `{ a = 10 * 2; }` works.
Recursive attribute sets are not yet implemented as we do not have any
kind of scope access yet anyways.
This is implemented using a new instruction that creates an attribute
set with a given number of elements by popping key/value pairs off the
stack.
Change-Id: I0f9aac7a131a112d3f66b131297686b38aaeddf2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6091
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Deriving Ord/Eq is required for the ordered BTreeMaps. Once interning
is implemented this will require some extra magic for the sort order,
but that's fine.
Change-Id: I0c654648eb3609a4a01d84868c25f43a4d35bc2e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6089
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
For some reason a top-level Rust project ended up in this location,
which is incompatible with the actual project structure that's being
prepared for merge right now.
Change-Id: I9d919ad72fc7e4e4d8cbb9899e7f8d90fa7ca87a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6060
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>
Autosubmit: tazjin <tazjin@tvl.su>
This representation should match what the Nix REPL shows for result
values.
Change-Id: If3143d969fcdc123a6029e2aeb7bbd6ae51aeb71
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6082
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: grfn <grfn@gws.fyi>
This isn't relevant to the value type itself.
Change-Id: I678bc92a8a530b1081ed498bf3ff7925217bcc01
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6081
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: grfn <grfn@gws.fyi>
These are a bit tricky to implement because Nix technically treats
them as identifiers, and only if the identifier is not explicitly
overridden within the scope does it yield the expected literal values.
Note that weirdness even occurs with scopedImport.
Change-Id: Ie55723405ccfcc25da37c5a08fa3332f37cf9ae5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6080
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: grfn <grfn@gws.fyi>
Implements simple arithmetic operations (+, -, *, /).
There is some scaffolding included to pop and coerce pairs of numbers,
as the Nix language will let arithmetic operators apply to arbitrary
pairs of number types (always resulting in floats if the types are
mixed).
Change-Id: I5f62c363bdea8baa6ef812cc64c5406759d257cf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6074
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This creates a REPL which outputs compiled bytecode, constants, and VM
results for code snippets.
Change-Id: If63f79a961456afd6a4cdf59b994107ff7ab8b47
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6072
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Autosubmit: tazjin <tazjin@tvl.su>
This can't do anything other than compute a single literal, for now
Change-Id: Ia28f9da51c906b590a198e77a4ca5d45a871106b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6071
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This compiler can only take care of very trivial literals so far.
Change-Id: I9dfac75a801b7235f868061a979ae24159fe1425
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6070
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
We are going to have a 1:1 drop-in replacement for the old-style nix
tools, and this starts implementing the cli parser part.
The first step is to have a simple integration test suite that can
verify that we match the nix CLI.
clap is a super complicated parsing library, but looking through the
rest they are either too opinioated to be of use for us, or depend on
clap as implementation.
Change-Id: I4cf6051f3a4f782c3242fd0d2b9eab3fbe33d8ad
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4756
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: Profpatsch <mail@profpatsch.de>
First steps for baba
Change-Id: Id6a68c5630cb85f280f4dcc7b2acf10c02454fd6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/4732
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
This adds the proto messages and service definition used for
communicating with our evaluator.
Please refer to the `Tvix - Component interaction` document for a
detailed description of the interactions that this service is used
for.
Change-Id: If44cdbff66c6cfe88c22a748fe29c0bbd8510b0d
Co-Authored-By: Florian Klink <flokli@flokli.de>
Co-Authored-By: Adam Höse <adisbladis@gmail.com>
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2685
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>
Reviewed-by: grfn <grfn@gws.fyi>
This is only the introductory text, without any of the components
specified so far.
Change-Id: I6cd8eff6ec2daf14cc2420ee0a8e8983bfaa57d9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3052
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: flokli <flokli@flokli.de>
Reviewed-by: sterni <sternenseemann@systemli.org>
We also want to access the produced SVGs separately.
Change-Id: I5bdfd95b8a56323ed8bf5f4585b703f6e728c677
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2742
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Most other docs folders in the repo are called `doc` too, let's make
this consistent.
Change-Id: Icd712429b51763076548c977321e370f2a77877e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2741
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
* general editing
* reflowed text to fit on my screen :p
Change-Id: I1ae41ef5524d3174d063c66a7bcb990808424bdb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2716
Tested-by: BuildkiteCI
Reviewed-by: adisbladis <adisbladis@gmail.com>
