Giter VIP home page Giter VIP logo

jrsonnet's People

Contributors

akursell-wish avatar bruno-delfino1995 avatar certainlach avatar dependabot-preview[bot] avatar dependabot[bot] avatar eagletmt avatar ebw44 avatar expelledboy avatar jackatbancast avatar jarviscraft avatar julienduchesne avatar messense avatar pawelbeza avatar simonswine avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jrsonnet's Issues

Assert support

Is assert support are implemented?

I test with the following code, usually is must trows an error:

local conf = {
    n: ""
};

conf + {
    assert std.isNumber(self.n)
}

Official output throw an error:

./test.jsonnet CLOSE_WRITE,CLOSE
RUNTIME ERROR: Object assertion failed.
	./test.jsonnet:6:12-32	thunk <object_assert>
	During manifestation	

With the crate jrsonnet-evaluator:0.3.6 output do not throw an error:

{"n": ""}

Below source code that I use:

use jrsonnet_evaluator::error::LocError;
use jrsonnet_evaluator::{EvaluationState, FileImportResolver};
...
let mut vm = EvaluationState::default();

vm.with_stdlib();

vm.set_import_resolver(Box::new(FileImportResolver {
    library_paths: vec![current_dir().unwrap()],
}));

let val = vm.evaluate_file_raw(&file.to_path_buf())?;

let val = vm.with_tla(val)?;

let output = vm.manifest(val).to_string();

Do I miss some things?

I see a TODO: Assert in the code of jrsonnet-evaluator is it link to this feature?

Manifesting a yaml tag

YAML has support for tags like:

includes:
- !include components/accounts.yaml

That !include is a directive that the code the uses to invoke some code-side constructor.
Weird, but it's supported. (yml in a nutshell)

When the yml document is manifested, the string is checked to see if it starts with a !, if it does, then it quotes the string.

I'm wondering if there's a workaround for this, or if we could change this.

bug(cli): command completion generation requires `<INPUT>` parameter

Description

Generating Clippy's tab-completions support requires the dummu <INPUT> parameter to be present.

Steps to reproduce

  1. Run
$ jrsonnet generate bash

bash can be replaced with any supported shell.

Expected behaviour

Tab-completion code is generated for the provided shell.

Observed behaviour

error: The following required arguments were not provided:
    <INPUT>

USAGE:
    jrsonnet [OPTIONS] <INPUT> [SUBCOMMAND]

For more information try --help

Tab-completion code is geneated only in presence of (any) <INPUT> parammeter value.

Differences in output compared to c-jsonnet

I am trying to migrate a very large jsonnet repo to use jrsonnet, and I have noticed the following differences in output from the same source as compared to the C implementation:

  • Empty arrays and objects do not contain a space between the brackets:
$ echo '[{}, []]' | jsonnet -
[
   { },
   [ ]
]
$ echo '[{}, []]' | jrsonnet -
[
   {},
   []
]
  • std.range(from, to) produces different output when to < from:
$ echo '[x for x in std.range(0, -3)]' | jsonnet -
[ ]
$ echo '[x for x in std.range(0, -3)]' | jrsonnet -
[
   0
]

It could be argued that calling range with to < from is UB, but outputting no elements in this case seems more correct than always outputting 1.

  • jrsonnet adds a newline when outputting zero items in a --yaml-stream:
$ echo '[]' | jsonnet -y -
$ echo '[]' | jrsonnet -y -

$

I'm not sure to what degree you are aiming for output compatibility with jsonnet and go-jsonnet, but if you are, these are the only differences I've found.

Optionnal feature preserving the order of fields in objects

Awesome work ! Your library is so fast and so easy to integrate with JS bindings (wasm-pack + wasm-bindgen).

I'm working on a project where object fields order matters : I use Jsonnet as templating tool like many others, and I need the output not to be alphanumerically sorted.
This kind of enhancement is well known and also needed by the community, see :
google/go-jsonnet#222
google/jsonnet#407
google/jsonnet#903

I partially managed to fix it in google/jsonnet except for binary plus operator (merge), and didn't manage to do it with google/go-jsonnet where sort order becomes quite random...
So I tried with jrsonnet and the result is just perfect and much more faster than others processors.
I just had to comment this line https://github.com/CertainLach/jrsonnet/blob/master/crates/jrsonnet-evaluator/src/obj.rs#L160 .
Could you please add an optionnal feature to preserve key ordering when processing ?
This feature exists for serde_json, for example and is named preserve_order : https://docs.serde.rs/serde_json/enum.Value.html#variant.Object.

code for benchmarks (large_string_join, etc.)

Hi there,
I am looking to use your bench suite here, to run it against a different Jsonnet implementation not covered in your comparison. would you mind sharing the code for the first 4 benchmarks? large_string_join, large_string_template, realistic1, realistic2

Thanks!

Add std.objectValues

Hello!
There are two functions from std library from v0.17.0 which looks missing in jrsonnet now:

std.objectValues(o)
Available since version 0.17.0.

Returns an array of the values in the given object. Does not include hidden fields.

std.objectValuesAll(o)
Available since version 0.17.0.

As std.objectValues but also includes hidden fields.

Could you implement them, please?

Use author matching the one in Git signature

Description

Cargo.tomls authors tag should use Yaroslav Bolyukin <[email protected]> used in git signing-off

Examples





Release non-x86-64 binaries

Description

Currently only x86-64 builds are released. Support for the remaining Tier-1 architectures should also be added as part of Release workflow.

Referring to earlier arguments in function argument default value expressions

First of all, thank you very much for this excellent implementation!

I have found a behavior difference between the official jsonnet and your implementation. It isn't a big deal, as it isn't great practice to have complex expressions in the default values anyway but I'd like to report it.

Given the input:

{
  f(a,b=a+1,c=b+1):: ( a + b + c ),
  x: self.f(1),
  y: self.f(1, b=10),
}

Official jsonnet renders:

{
  "x": 6,
  "y": 22
}

but Jrsonnet gives:

variable is not defined: a

General expressions and references to other defined variables work in the default value expressions, so I speculate this is only about the previous argument value not being visible in the expressions for b and c.

Note that the official jsonnet doesn't do it dynamically and always uses the value calculated at the time of the function definition which can be seen in the 'y' output.

Feel free to close it if you think this is just an artifact of the official implementation and doesn't worth supporting.

Implement multiline string literal syntax

Description

Currently multiline string literal (|||) syntax is unsupported by parser and should be implemented to guarantee full spec-compatibility.

Details

Expr::Str should be created for ||| string literals.
Alternatively, a specific Expr may be added like MultilineStr(Vec<String>).

Example

... of a valid expression using ||| syntax:

{
  'foo': |||
    bar
    baz
    qux
  |||
}

the trait `Trace` is not implemented for `Rc<anyhow::Error>`

How to reproduce

git checkout v0.4.2
cargo build -F "anyhow-error"
error[E0277]: the trait bound `Rc<anyhow::Error>: Trace` is not satisfied
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ the trait `Trace` is not implemented for `Rc<anyhow::Error>`
   |
   = help: the following other types implement trait `Trace`:
             Rc<Path>
             Rc<str>
note: required by a bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::trace::mark`
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ required by this bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::trace::mark`
   = note: this error originates in the derive macro `Trace` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Rc<anyhow::Error>: Trace` is not satisfied
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ the trait `Trace` is not implemented for `Rc<anyhow::Error>`
   |
   = help: the following other types implement trait `Trace`:
             Rc<Path>
             Rc<str>
note: required by a bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::root::mark`
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ required by this bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::root::mark`
   = note: this error originates in the derive macro `Trace` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Rc<anyhow::Error>: Trace` is not satisfied
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ the trait `Trace` is not implemented for `Rc<anyhow::Error>`
   |
   = help: the following other types implement trait `Trace`:
             Rc<Path>
             Rc<str>
note: required by a bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::unroot::mark`
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ required by this bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::unroot::mark`
   = note: this error originates in the derive macro `Trace` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `Rc<anyhow::Error>: Trace` is not satisfied
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ the trait `Trace` is not implemented for `Rc<anyhow::Error>`
   |
   = help: the following other types implement trait `Trace`:
             Rc<Path>
             Rc<str>
note: required by a bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::finalize_glue::mark`
  --> crates/jrsonnet-evaluator/src/error.rs:15:31
   |
15 | #[derive(Error, Debug, Clone, Trace)]
   |                               ^^^^^ required by this bound in `_DERIVE_jrsonnet_gc_Trace_FOR_Error::<impl Trace for error::Error>::finalize_glue::mark`
   = note: this error originates in the derive macro `Trace` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
warning: `jrsonnet-evaluator` (lib) generated 40 warnings
error: could not compile `jrsonnet-evaluator` due to 4 previous errors; 40 warnings emitted

jrsonnet 0.3.4 panics with TLS error on macos

This is using version 0.3.4 of jrsonnet-darwin-amd64.

$ echo '{}' | RUST_BACKTRACE=full jrsonnet -
{ }
thread '<unnamed>' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', /rustc/e1884a8e3c3e813aada8254edfa120e85bf5ffca/library/std/src/thread/local.rs:248:26
stack backtrace:
   0:        0x10920489f - __mh_execute_header
   1:        0x10917b6d0 - __mh_execute_header
   2:        0x109204076 - __mh_execute_header
   3:        0x109203ad2 - __mh_execute_header
   4:        0x1092033d2 - __mh_execute_header
   5:        0x109220549 - __mh_execute_header
   6:        0x1092204b8 - __mh_execute_header
   7:        0x109220460 - __mh_execute_header
   8:        0x10922a90f - __mh_execute_header
   9:        0x10922af05 - __mh_execute_header
  10:        0x1091e3427 - __mh_execute_header
  11:        0x10918811b - __mh_execute_header
  12:        0x109187423 - __mh_execute_header
  13:        0x1091db241 - __mh_execute_header
  14:        0x109220152 - __mh_execute_header
  15:     0x7fff20366555 - <unknown>
  16:     0x7fff20279f8b - <unknown>
Abort trap: 6

assertion failed on Winodws x86 in debug mode

https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133

stacktrace:

thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `2`,
 right: `1`', C:\Users\runneradmin\.cargo\git\checkouts\jrsonnet-22393f555b7197c5\153383c\crates\jrsonnet-interner\src\lib.rs:88:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `2`,
 right: `1`', C:\Users\runneradmin\.cargo\git\checkouts\jrsonnet-22393f555b7197c5\153383c\crates\jrsonnet-interner\src\lib.rs:88:17
stack backtrace:
   0: 0x7423844a - core::fmt::write
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\core\src\fmt\mod.rs:1213
   1: 0x7421d871 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\io\mod.rs:1682
   2: 0x74220d15 - std::sys_common::backtrace::_print
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\sys_common\backtrace.rs:47
   3: 0x74220d15 - std::sys_common::backtrace::print
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\sys_common\backtrace.rs:34
   4: 0x74222c87 - std::panicking::default_hook::closure$1
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\panicking.rs:267
   5: 0x742228c9 - std::panicking::default_hook
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\panicking.rs:286
   6: 0x74223465 - std::panicking::rust_panic_with_hook
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\panicking.rs:688
   7: 0x74223225 - std::panicking::begin_panic_handler::closure$0
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\panicking.rs:579
   8: 0x7422188a - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\sys_common\backtrace.rs:137
   9: 0x74222ea4 - std::panicking::begin_panic_handler
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\panicking.rs:575
  10: 0x7423fc4f - core::panicking::panic_fmt
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\core\src\panicking.rs:64
  11: 0x7423ffd7 - core::panicking::assert_failed_inner
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\core\src\panicking.rs:258
  12: 0x74206ba9 - core::panicking::assert_failed<u32,u32>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\panicking.rs:212
  13: 0x741f1e28 - jrsonnet_interner::impl$6::drop
                       at C:\Users\runneradmin\.cargo\git\checkouts\jrsonnet-22393f555b7197c5\153383c\crates\jrsonnet-interner\src\lib.rs:93
  14:   0xbedf04 - <unknown>
  15: 0x7419176f - core::ptr::drop_in_place<enum2$<core::option::Option<jrsonnet_interner::IStr> > >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  16: 0x740c07d8 - core::ptr::drop_in_place<jrsonnet_evaluator::FileData>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  17: 0x740c3fbd - core::ptr::drop_in_place<tuple$<jrsonnet_parser::source::SourcePath,jrsonnet_evaluator::FileData> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  18: 0x7415d76b - core::ptr::mut_ptr::impl$0::drop_in_place
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mut_ptr.rs:1451
  19: 0x7415d76b - hashbrown::raw::Bucket<tuple$<jrsonnet_parser::source::SourcePath,jrsonnet_evaluator::FileData> >::drop<tuple$<jrsonnet_parser::source::SourcePath,jrsonnet_evaluator::FileData> >
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba1[50](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:51)01f\hashbrown-0.13.2\src\raw\mod.rs:344
  20: 0x7415c659 - hashbrown::raw::impl$16::drop<tuple$<jrsonnet_parser::source::SourcePath,jrsonnet_evaluator::FileData>,hashbrown::raw::alloc::inner::Global>
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hashbrown-0.13.2\src\raw\mod.rs:1874
  21: 0x740bf8fd - core::ptr::drop_in_place<hashbrown::map::HashMap<jrsonnet_parser::source::SourcePath,jrsonnet_evaluator::FileData,core::hash::BuildHasherDefault<rustc_hash::FxHasher>,hashbrown::raw::alloc::inner::Global> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  22: 0x740bf04d - core::ptr::drop_in_place<core::cell::UnsafeCell<jrsonnet_evaluator::gc::GcHashMap<jrsonnet_parser::source::SourcePath,jrsonnet_evaluator::FileData> > >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  23: 0x740c2115 - core::ptr::drop_in_place<jrsonnet_evaluator::EvaluationStateInternals>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  24: 0x740915dd - core::mem::manually_drop::ManuallyDrop<jrsonnet_evaluator::EvaluationStateInternals>::drop<jrsonnet_evaluator::EvaluationStateInternals>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\mem\manually_drop.rs:144
  25: 0x7412cf65 - jrsonnet_gcmodule::cc::drop_ccbox<jrsonnet_evaluator::EvaluationStateInternals,jrsonnet_gcmodule::collect::ObjectSpace>
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\jrsonnet-gcmodule-0.3.5\src\cc.rs:559
  26: 0x7413ccd5 - jrsonnet_gcmodule::cc::impl$17::drop<jrsonnet_evaluator::EvaluationStateInternals,jrsonnet_gcmodule::collect::ObjectSpace>
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\jrsonnet-gcmodule-0.3.5\src\cc.rs:583
  27: 0x740bec0d - core::ptr::drop_in_place<jrsonnet_gcmodule::cc::RawCc<jrsonnet_evaluator::EvaluationStateInternals,jrsonnet_gcmodule::collect::ObjectSpace> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  28:   0xbee11c - <unknown>
  29: 0x741ffba8 - core::ptr::drop_in_place<slice2$<alloc::boxed::Box<dyn$<jrsonnet_gcmodule::cc::GcClone>,alloc::alloc::Global> > >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  30: 0x74201c89 - alloc::vec::impl$27::drop<alloc::boxed::Box<dyn$<jrsonnet_gcmodule::cc::GcClone>,alloc::alloc::Global>,alloc::alloc::Global>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\alloc\src\vec\mod.rs:3059
  31: 0x741fe686 - jrsonnet_gcmodule::collect::release_unreachable<jrsonnet_gcmodule::collect::GcHeader,tuple$<> >
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\jrsonnet-gcmodule-0.3.5\src\collect.rs:436
  32: 0x741fe686 - jrsonnet_gcmodule::collect::release_unreachable<jrsonnet_gcmodule::collect::GcHeader,tuple$<> >
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\jrsonnet-gcmodule-0.3.5\src\collect.rs:436
  33: 0x741fda8d - jrsonnet_gcmodule::collect::collect_list<jrsonnet_gcmodule::collect::GcHeader,tuple$<> >
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\jrsonnet-gcmodule-0.3.5\src\collect.rs:274
  34: 0x741fd760 - jrsonnet_gcmodule::collect::ObjectSpace::collect_cycles
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\jrsonnet-gcmodule-0.3.5\src\collect.rs:155
  35: 0x741fd7bd - jrsonnet_gcmodule::collect::impl$3::drop
                       at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\jrsonnet-gcmodule-0.3.5\src\collect.rs:179
  36: 0x741ffb33 - core::ptr::drop_in_place<enum2$<core::option::Option<jrsonnet_gcmodule::collect::ObjectSpace> > >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  37: 0x741ff70d - core::ptr::drop_in_place<std::thread::local::lazy::LazyKeyInner<jrsonnet_gcmodule::collect::ObjectSpace> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  38: 0x741ff818 - core::ptr::drop_in_place<alloc::boxed::Box<std::thread::local::os::Value<jrsonnet_gcmodule::collect::ObjectSpace>,alloc::alloc::Global> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  39: 0x741ffb33 - core::ptr::drop_in_place<enum2$<core::option::Option<jrsonnet_gcmodule::collect::ObjectSpace> > >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  40: 0x741ff70d - core::ptr::drop_in_place<std::thread::local::lazy::LazyKeyInner<jrsonnet_gcmodule::collect::ObjectSpace> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  41: 0x741ff818 - core::ptr::drop_in_place<alloc::boxed::Box<std::thread::local::os::Value<jrsonnet_gcmodule::collect::ObjectSpace>,alloc::alloc::Global> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\core\src\ptr\mod.rs:490
  42: 0x74202a[51](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:52) - std::thread::local::os::destroy_value::closure$0<jrsonnet_gcmodule::collect::ObjectSpace>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\std\src\thread\local.rs:1149
  43: 0x74202c4d - std::panicking::try::do_call<std::thread::local::os::destroy_value::closure_env$0<jrsonnet_gcmodule::collect::ObjectSpace>,tuple$<> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\std\src\panicking.rs:483
  44: 0x74202bcf - std::panicking::try<tuple$<>,std::thread::local::os::destroy_value::closure_env$0<jrsonnet_gcmodule::collect::ObjectSpace> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\std\src\panicking.rs:447
  45: 0x74202804 - std::thread::local::os::destroy_value<jrsonnet_gcmodule::collect::ObjectSpace>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\std\src\thread\local.rs:1145
  46: 0x74202bcf - std::panicking::try<tuple$<>,std::thread::local::os::destroy_value::closure_env$0<jrsonnet_gcmodule::collect::ObjectSpace> >
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\std\src\panicking.rs:447
  47: 0x74202804 - std::thread::local::os::destroy_value<jrsonnet_gcmodule::collect::ObjectSpace>
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d\library\std\src\thread\local.rs:1145
  48: 0x742272be - std::sys::windows::thread_local_key::run_dtors
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\sys\windows\thread_local_key.rs:277
  49: 0x742272be - std::sys::windows::thread_local_key::on_tls_callback
                       at /rustc/5e37043d63bfe2f3be8fa5a05b07d6c0dad5775d/library\std\src\sys\windows\thread_local_key.rs:244
  50: 0x7789af69 - LdrHotPatchNotify
  51: 0x77883be6 - LdrDeleteEnclave
  [52](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:53): 0x7786714e - RtlDeactivateActivationContextUnsafeFast
  [53](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:54): 0x778672a3 - RtlDeactivateActivationContextUnsafeFast
  [54](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:55): 0x778678cd - LdrShutdownProcess
  [55](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:56): 0x7786a925 - RtlExitUserProcess
  [56](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:57): 0x76bc8e93 - ExitProcess
  [57](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:58): 0x76536244 - exit
  [58](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:59): 0x76536171 - exit
  [59](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:60):   0x701266 - <unknown>
  [60](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:61): 0x76bb6a39 - BaseThreadInitThunk
  [61](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:62): 0x77877d1d - RtlGetFullPathName_UEx
  [62](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:63): 0x[77](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:78)[87](https://github.com/messense/rjsonnet-py/actions/runs/3982495683/jobs/6827010133#step:6:88)7ceb - RtlGetFullPathName_UEx
thread panicked while panicking. aborting.

debug_assert_eq!(Inner::strong_count(inner), 1);

Suggestion: avoid forcing defauld parameters order

In the official implementation, defauld parameters are not required to be used after all positionals, I wonder if it would be possible to make jrsonnet behave the same?

Only removing the check in crates/jsonnet-parser/src/lib.rs (line 62) seems to enable this behaviour without regression, what do you think @CertainLach?

Help extracting details of an exported function parameter

I have a use case where I want to determine the details (name, type, and default value) of an exported Jsonnet function. My current approach works for parameters with default values that are plain value expressions (function (a=1, b="two", c=null)) but fails when the default value references a value or function defined elsewhere in the file:

        if let Val::Func(func) = exported_value {
            if let FuncVal::Normal(func) = func.as_ref() {
                for param in func.params.iter() {
                    if let Some(expr) = &param.1 {
                        let val = state
                            .evaluate_expr_raw(expr.clone())

Is there a better way to evaluate a LocExpr in the global context to determine what the value it produces will be?

Thanks for your help!

New release?

Hello!

I wonder when we could expect a new Jrsonnet release?

'no such field' error

I have a project that does some meta programming in jsonnet and it fails with an error when using jrsonnet, it works with the Go/C++ jsonnet.

Steps to reproduce:

$ jb init && jb install github.com/crdsonnet/kube-state-metrics-libsonnet/ksm-custom
$ curl -sL https://github.com/CertainLach/jrsonnet/releases/download/v0.5.0-pre5-test/jrsonnet-linux-amd64 -O
$ chmod +x ./jrsonnet-linux-amd64
$ ./jrsonnet-linux-amd64 -J vendor -S -c -m docs/ \
      --exec "(import 'doc-util/main.libsonnet').render(import 'ksm-custom/main.libsonnet')"

Output:

no such field: customResourceStateMetrics
    vendor/github.com/crdsonnet/kube-state-metrics-libsonnet/ksm-custom/main.libsonnet:16:8-42: field <customResourceStateMetrics> access
    <cmdline>:1:43-78:                                                                          import "ksm-custom/main.libsonnet"
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:401:35-39:               variable <obj> access
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:348:27-31:               variable <obj> access
    <std>:0:0:                                                                                  variable <o> access
    argument <obj> evaluation
    <std>:0:0:                                                                                  function <builtin_object_fields_ex> call
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:348:7-32:                function <objectFieldsAll> call
    argument <arr> evaluation
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:271:6-271:7:             function <builtin_foldl> call
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:401:22-40:               function <prepare> call
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:381:21-29:               variable <package> access
    argument <x> evaluation
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:381:10-42:               function <builtin_length> call
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:381:14-381:15:           if condition
    vendor/github.com/jsonnet-libs/docsonnet/doc-util/render.libsonnet:401:5-41:                function <renderFiles> call
    <cmdline>:1:1-79:                                                                           function <render> call

I also tried with 0.4.2, same result.

Output in the same order as defined

Is there any practical reason, or laid out by the spec, on why the fields get ordered when manifesting?

I plan on using the order of the fields to determine how kct applies resources to the cluster. But as the fields get ordered during manifestation, I'm a bit lost and can't find an alternative on what else to use. Honestly, setting my interests with kct aside, I find it a little strange to have the rendered fields in a different order than what I defined in my templates.

I checked that the official implementation does the same, and it seems that you aim to have similar output. I hope it isn't too much of a stretch to ask for this, but can we leave the order of the fields as defined in the templates?

Function parameter defaults cannot depend on prior argument values, regression compared to other implementations

local test = function(a, b=a.y) a.x + b;

[
  test({x: 'x', y: 'y'}),
  test({x: 'x', y: 'y'}, 'b'),
  test({x: 'x'}, 'b'),
]

Results:

$ jsonnet test.jsonnet                                                        
[
   "xy",
   "xb",
   "xb"
]

$ go-jsonnet test.jsonnet
[
   "xy",
   "xb",
   "xb"
]

$ jrsonnet test.jsonnet                                                        
variable is not defined: a
    /<path>/test.jsonnet:3:28-30: variable <a>
    /<path>/test.jsonnet:3:39-41: variable <b>
    /<path>/test.jsonnet:6:3-26 : function <test> call

No codegenerated-stdlib feature in jrsonnet-evaluator crate

https://github.com/CertainLach/jrsonnet/tree/master/crates/jrsonnet-evaluator#standard-library

[dependencies]
jrsonnet-evaluator = { version = "0.3.8", features = ["codegenerated-stdlib"] }

throws

error: failed to select a version for `jrsonnet-evaluator`.
    ... required by package `rjsonnet v0.3.0 (/Users/messense/Projects/rjsonnet-py)`
versions that meet the requirements `=0.3.8` are: 0.3.8

the package `rjsonnet` depends on `jrsonnet-evaluator`, with features: `codegenerated-stdlib` but `jrsonnet-evaluator` does not have these features.


failed to select a version for `jrsonnet-evaluator` which could resolve this conflict

Comprehension inheritance causes syntax error

jrsonnet version: 0.4.2

Using a comprehension to create an inheritable object causes a syntax error within the comprehension.

For example:

{
    updateInnerField1:: {
        [outerField]+: {
            innerField1: "from update",
        }
        for outerField in ["outerField1"]
    },

    o1: {
        outerField1: {
            innerField1: "original",
            innerField2: "original",
        },
    } + $.updateInnerField1,
}

The expected output is:

{
   "o1": {
      "outerField1": {
         "innerField1": "from update",
         "innerField2": "original"
      }
   }
}

but with jrsonnet we hit a syntax error on line 6, column 9 (beginning of the "for" in the comprehension):
syntax error, expected one of one of "(", ".", "[", "{", "}", <binary op>, <whitespace>, got "f"

Changing the line [outerField]+: { to [outerField]: { fixes the syntax issue, but of course it changes the results, completely overwriting the object instead of only overwriting the value for innerField1.

Additionally, unfurling the comprehension also resolves the issue, so it seems like the combination of using a derived field ([outerField]) and inheritance using +: causes the issue.

The same syntax error arises when attempting the same but with a list instead of an object:

{
    updateOuterField1:: {
        [outerField]+: ["from update"],
        for outerField in ["outerField1"]
    },

    o1: {
        outerField1: ["original"],
    } + $.updateOuterField1,
}

where we expect the output to be

{
   "o1": {
      "outerField1": [
         "original",
         "from update"
      ]
   }
}

Recommendations for server-side evaluation of untrusted Jsonnet?

Thanks so much for creating this library!

The Jsonnet website has a warning about server-side Jsonnet evaluation.

Is there a safe way to evaluate untrusted Jsonnet using jrsonnet on the server-side? For example, by limiting the max stack size, the size of the inputs, etc. Are there any other settings / considerations you would recommend for this setup?

In a similar vein, the jrsonnet CLI implementation spawns a separate thread to run the evaluator. I'm assuming one would want to do the same on the server side, but probably use a thread pool and ensure that panics in the various threads are not propagated to the API handling the requests. Would you agree with that approach?

'-' for stdin

I would like to dynamically generate and pass my root jsonnet in via stdin.
e.g.

collect_files.sh | jrsonnet -

- is pretty universally accepted as a hint to the process to read its primary file from stdin instead of a file path.
FWIW, The C++ jsonnet app supports this.

panicking on file input

When using jrsonnet version 3.7 (both linux versions) I get the following error:

jrsonnet testing.jsonnet
thread 'main' panicked at 'called Option::unwrap() on a None value', crates/jrsonnet-cli/src/lib.rs:48:16
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

With backtrace :

thread 'main' panicked at 'called Option::unwrap() on a None value', crates/jrsonnet-cli/src/lib.rs:48:16
stack backtrace:
0: 0x5574508f5e50 - std::backtrace_rs::backtrace::libunwind::trace::hfa838fc631229987
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
1: 0x5574508f5e50 - std::backtrace_rs::backtrace::trace_unsynchronized::h93a23e36ec026219
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x5574508f5e50 - std::sys_common::backtrace::_print_fmt::hba56c7f796a4152f
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/sys_common/backtrace.rs:67:5
3: 0x5574508f5e50 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h214637f1e26310e1
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/sys_common/backtrace.rs:46:22
4: 0x55745091691c - core::fmt::write::h7aa6cd0067dca82a
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/core/src/fmt/mod.rs:1110:17
5: 0x5574508f3a15 - std::io::Write::write_fmt::heb07fc0616bbd06d
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/io/mod.rs:1588:15
6: 0x5574508f7eab - std::sys_common::backtrace::_print::h2c2441c37e894fb5
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/sys_common/backtrace.rs:49:5
7: 0x5574508f7eab - std::sys_common::backtrace::print::h4fb679ac439362ea
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/sys_common/backtrace.rs:36:9
8: 0x5574508f7eab - std::panicking::default_hook::{{closure}}::h56bbadec2356e5d2
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panicking.rs:208:50
9: 0x5574508f7981 - std::panicking::default_hook::hb25822b45f6fdc4e
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panicking.rs:225:9
10: 0x5574508f8551 - std::panicking::rust_panic_with_hook::h4da5578e7277d2d4
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panicking.rs:622:17
11: 0x5574508f8027 - std::panicking::begin_panic_handler::{{closure}}::h003783ddb3cba4e8
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panicking.rs:517:13
12: 0x5574508f632c - std::sys_common::backtrace::__rust_end_short_backtrace::hd138d2032731ed21
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/sys_common/backtrace.rs:141:18
13: 0x5574508f7fb9 - rust_begin_unwind
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panicking.rs:515:5
14: 0x55745051c3c1 - core::panicking::panic_fmt::hbe99dddd3092ba3c
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/core/src/panicking.rs:92:14
15: 0x55745051c30d - core::panicking::panic::h3de4db67bd397eb3
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/core/src/panicking.rs:50:5
16: 0x557450847a8d - core::option::Option::unwrap::hf95404a03dcdec27
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/core/src/option.rs:388:21
17: 0x5574505505be - <jrsonnet_cli::MiscOpts as clap::derive::FromArgMatches>::from_arg_matches::he5b374a4e6d116b3
at /mnt/StorageArray0/Development/Local/jrsonnet/crates/jrsonnet-cli/src/lib.rs:48:13
18: 0x5574505507d9 - <jrsonnet_cli::GeneralOpts as clap::derive::FromArgMatches>::from_arg_matches::h2995351b89fa82a7
at /mnt/StorageArray0/Development/Local/jrsonnet/crates/jrsonnet-cli/src/lib.rs:76:9
19: 0x557450522b3c - <jrsonnet::Opts as clap::derive::FromArgMatches>::from_arg_matches::h7c3532fa81d7424d
at /mnt/StorageArray0/Development/Local/jrsonnet/cmds/jrsonnet/src/main.rs:57:9
20: 0x5574505265f7 - clap::derive::Clap::parse::h8a0c6a0b506304c0
at /home/userd/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-3.0.0-beta.2/src/derive.rs:77:9
21: 0x55745051f749 - jrsonnet::main::ha4593186b5a63a22
at /mnt/StorageArray0/Development/Local/jrsonnet/cmds/jrsonnet/src/main.rs:68:19
22: 0x5574505276bb - core::ops::function::FnOnce::call_once::h5a5a17fc330bc772
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/core/src/ops/function.rs:227:5
23: 0x55745051e68e - std::sys_common::backtrace::__rust_begin_short_backtrace::h953e20ac34f306ce
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/sys_common/backtrace.rs:125:18
24: 0x55745051d601 - std::rt::lang_start::{{closure}}::ha22dadcb0fa00322
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/rt.rs:49:18
25: 0x5574508f8a49 - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::hd933294140eb11aa
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/core/src/ops/function.rs:259:13
26: 0x5574508f8a49 - std::panicking::try::do_call::h8342fe3d9218b807
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panicking.rs:401:40
27: 0x5574508f8a49 - std::panicking::try::hcbd73d6d0d58a8f0
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panicking.rs:365:19
28: 0x5574508f8a49 - std::panic::catch_unwind::hde9cf73f810acfcc
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/panic.rs:434:14
29: 0x5574508f8a49 - std::rt::lang_start_internal::heb39e7ea6e5d6f6f
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/rt.rs:34:21
30: 0x55745051d5e0 - std::rt::lang_start::hbb8edbeabd2afdfa
at /rustc/e4a60327063e82413eed50a10df3b7d19b77bda0/library/std/src/rt.rs:48:5
31: 0x557450522f2c - main
32: 0x7fba01e8db25 - __libc_start_main
33: 0x55745051cbbe - _start
34: 0x0 -

The issue is not present with version 3.5.

Kind regards

Panic on evaluation of array

The evaluation of the snippet [std.extVar('foo')] results in a panic:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', jrsonnet/crates/jrsonnet-evaluator/src/lib.rs:136:47
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/panicking.rs:50:5
   3: std::thread::local::LocalKey<T>::with
   4: jrsonnet_evaluator::evaluate::evaluate
   5: jrsonnet_evaluator::evaluate::evaluate
   6: jrsonnet_evaluator::evaluate::evaluate_apply
   7: jrsonnet_evaluator::evaluate::evaluate
   8: <jrsonnet_evaluator::evaluate::evaluate::ArrayElement as jrsonnet_evaluator::val::LazyValValue>::get
   9: jrsonnet_evaluator::val::LazyVal::evaluate
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
  11: jrsonnet_evaluator::integrations::serde::<impl core::convert::TryFrom<&jrsonnet_evaluator::val::Val> for serde_json::value::Value>::try_from
use std::convert::TryFrom;
use std::path::Path;

pub fn main() {
    let snippet = "[std.extVar('foo')]";
    let vm = jrsonnet_evaluator::EvaluationState::default();
    vm.with_stdlib();
    vm.settings_mut().ext_vars.insert("foo".into(), jrsonnet_evaluator::Val::Str("foo".into()));
    let value = vm.evaluate_snippet_raw(Path::new("snippet").into(), snippet.into()).unwrap();
    serde_json::Value::try_from(&value).unwrap();
}

Unfortunately, I'm not very familiar with code base and haven't been able to come up with a proper fix myself.

Support for big integers

Hello!

Would it be possible to improve the current integer precision? I understand that all numbers in Jsonnet are represented as double (as defined in IEEE754), but for very big integers (larger than 2^53 IIRC) this gives a pretty poor precision.

If sticking to the language specifications is the priority, maybe it could be considered to add "big numbers" features in the standard library? Or something else?

WDYT?

Unable to chain --jpath and JSONNET_PATH seems unused

Hello @CertainLach, great work you have done here!

I'm wondering if it is planned to add the possibility to chain --jpath arguments, or at least a way to put multiple paths in the argument as it is limited to only one right now?

In addition, it seems the variable JSONNET_PATH (mentioned in the 'help') is not used and updating it seems to have no effect at all (that would be one solution to give multiple paths, even if not the most beautiful)

Best regards :)

Bigint equality is missing

std.primitiveEquals is missing implementation for two bigints. That means,

std.bigint('0') == std.bigint('0')
// false

However, as std.__compare IS implemented for the two, a temporary solution will be:

local bigintEq(a, b) = a >= b && a <= b;
bigintEq(std.bigint('0'), std.bigint('0'))
// true

`--exec` should stringify output, instead of manifestification

This is really minor and as far as I can tell not part of the spec, however wanted to note that empty objects are emitted without a space between the braces ({}), which is different ({ }) compared to both the C++ and go jsonnet versions as well as sjsonnet.

Examples:

❯ jsonnet -e '{ }'
{ }
❯ jrsonnet -e '{ }'
{}

Thanks for the effort on this project! My anecdotal benchmarking against a slightly modified kube-prometheus configuration runs in ~500ms vs sjsonnet @ ~3s, jsonnet (go) @ ~15s, and jsonnet (C++) @ 120s. Coming from the C++ version (I wasn't aware of the go port and sjsonnet failed last time I tried it), this ran so fast that I thought it must surely be broken!

foldr func argument is called with the wrong arument order compared to other implementations

{
  foldr: std.foldr((function(element, acc) acc || element == 'e'), ['t', 'e', 's', 't'], false),
  foldl: std.foldl((function(acc, element) acc || element == 'e'), ['t', 'e', 's', 't'], false),
}
$ jsonnet test.jsonnet
{
   "foldl": true,
   "foldr": true
}

$ go-jsonnet test.jsonnet
{
   "foldl": true,
   "foldr": true
}

$ jrsonnet test.jsonnet  
binary operation string || boolean is not implemented
    /<path>/test.jsonnet:2:10-97: function <std.foldr> call
                                              : field <foldr> manifestification

However, changing the code to this works with jrsonnet, but breaks the other implementations

{
  foldr: std.foldr((function(acc, element) acc || element == 'e'), ['t', 'e', 's', 't'], false),
  foldl: std.foldl((function(acc, element) acc || element == 'e'), ['t', 'e', 's', 't'], false),
}

function evaluation unwrap error

function(config={})
{
  [if 1 == 1 then "item" + std.toString(x)]: x for x in std.range(0,2)
}

When evaluation above code, it panicked:

thread 'main' panicked at 'called Option::unwrap() on a None value', crates/jrsonnet-evaluator/src/lib.rs:128:17
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

I tracked the call stacks and found it may be causd by stdlib missing.
Is there any reason that not importing the stdlib in function scope? I tried with go-jsonnet and it's fine.

jrsonnet-evaluator 0.4.2 `EvaluationState::stringify_err` panics with empty source code

Thanks for the library - I've found it very powerful.

I've run into the following edge case when evaluating empty files. The following code panics, but it should correctly format the error.

use std::{
    path::{Path, PathBuf},
    rc::Rc,
};

use jrsonnet_evaluator::{EvaluationState, FileImportResolver, ManifestFormat};

fn main() {
    let vm = EvaluationState::default();
    vm.with_stdlib();
    vm.set_manifest_format(ManifestFormat::Json(0));
    vm.set_import_resolver(Box::new(FileImportResolver::default()));

    // println!("Evaluating 0");
    // run(&vm, "0");
    // println!("Evaluating syntax error");
    // run(&vm, "syntax error");
    println!("Evaluating empty");
    run(&vm, "");
}

fn run(vm: &EvaluationState, code: &str) {
    let source: Rc<Path> = PathBuf::new().into();
    let result = vm.evaluate_snippet_raw(source.clone(), code.into());

    match result {
        Ok(v) => eprintln!("  no error: {:?}", v),
        Err(e) => {
            eprintln!("  LocError: {:?}", e);
            eprintln!("  stringify_err:");
            eprintln!("    {}", vm.stringify_err(&e));  // This panics when code == "".
        }
    }
}

Stack trace:

Evaluating empty
  LocError: LocError((ImportSyntaxError { path: "", source_code: "", error: ParseError { location: LineCol { line: 1, column: 1, offset: 0 }, expected: ExpectedSet { expected: {"\"[\"", "\"{\"", "<number>", "\"(\"", "<string>", "<whitespace>", "<identifier>", "<unary op>"} } } }, StackTrace([])))
  stringify_err:
thread 'main' panicked at 'attempt to subtract with overflow', /home/huin/.cargo/registry/src/github.com-1ecc6299db9ec823/jrsonnet-evaluator-0.4.2/src/trace/mod.rs:101:26
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:48:5
   3: <jrsonnet_evaluator::trace::CompactFormat as jrsonnet_evaluator::trace::TraceFormat>::write_trace
             at /home/huin/.cargo/registry/src/github.com-1ecc6299db9ec823/jrsonnet-evaluator-0.4.2/src/trace/mod.rs:101:14
   4: jrsonnet_evaluator::EvaluationState::stringify_err
             at /home/huin/.cargo/registry/src/github.com-1ecc6299db9ec823/jrsonnet-evaluator-0.4.2/src/lib.rs:328:3
   5: jrsonnet_panic::run
             at ./src/main.rs:31:33
   6: jrsonnet_panic::main
             at ./src/main.rs:19:5
   7: core::ops::function::FnOnce::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

The commented out code (if uncommented) runs without a panic, for comparison.

It looks like the affected line has already been fixed in [df9bc99], so it's just pending a release.

Regression in bench.02.jsonnet

This bench was used to be very fast (took around 1ms) before, but on latest release it tooks around 5 minutes

local Fib = {
  n: 1,
  local outer = self,
  r: if self.n <= 1 then 1 else (Fib { n: outer.n - 1 }).r + (Fib { n: outer.n - 2 }).r,
};

(Fib { n: 25 }).r

cargo install?

is it possible to cargo install the jrsonnet CLI? If not, would it be possible to support this mode of installation?

I see the jrsonnet crate was yanked from crates.io. I also didn't see the jrsonnet-cli published on crates.io.

Release 0.3.0 is missing the last commit

The code from the last commit of Release 0.3.0 is not present on the package published at crates.io.

I checked that it does exist within the zipped code. But when using jrsonnet-evaluator = "0.3.0" on my dependencies, I get this code, which is different from what is under the tag 0.3.0.

From what I saw, the release workflow only publishes to GitHub release and not to crates.io. Could it have been a problem when manually publishing the crate?

Build statically linked binary

When I run the following command, as suggested in README.md:

cargo build --release

it results in a dynamically linked binary, which runs great locally, but I'm unable to run it on other machines, for example, in a docker image.

The releases page includes statically linked binaries. What is the command or config used to create these? If possible, could these commands be included in the README.md file for future reference?

Thanks for your help!

defining functions in object comprehensions

I have encountered following corner case in one of our jsonnets:

Input:

local funcs = {
  [a](x): x * 2
  for a in ["f1", "f2", "f3"]
};
funcs.f1(10)

Official jsonnet output:

20

Jrsonnet output:

syntax error: expected one of "(", ".", "[", "{", "}", <binary op>, got "f"
    gurer.jsonnet:3:3

One way to avoid this is to use [a]: function(x) x * 2 form which works in both implementations and a cleaner form anyway. But I'd wanted to report this just in case.

jrsonnet fails to compile on MacOs

Issue:
I get the following error on trying to compile jrsonnet:

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-m64" "-arch" "x86_64" "-L" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.12h9iougnfbidh8d.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.13hlm373ewj1xsvu.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.15okmk7tci5c467q.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.162c9b9eprx0t4s4.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.18e1cghkojy22c48.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.194xtndyhleyw35v.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.19k6r73mvb9c3uxt.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1ayllzkgxevdxfyy.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1bpqe3i9t2itb8jc.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1elogh34clb2jbp3.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1iyb5imdw1gd5st0.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1jwpucds0radxpp6.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1kvqshf8q5csv6vm.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1po7db08k0ei0aor.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1sf2xfq849tgg7o.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1sf37y1kubdycmw.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1tkic8t5umdlv4sz.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1uy1mbu3z3iudrej.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.1winz8wf6kh0o00s.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.21qejrzjz99u7gpt.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.238je83bzcyanqoh.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.23wuc872fr1n855k.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2fxnm5u1dev4iob7.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2g57ac2f3gew077z.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2gtp8xj4ij8tzwdv.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2letgbds6kgv8ovu.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2ljblpzbdp6shq57.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2rh8ifw4h777z3o.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2sfidoms6yeuntsw.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.2wu6bhs9hwfdlnx0.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.30yagm6654wpp1f0.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.314bv1n7522luvmg.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.32351vwyzygbptwd.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.341qy3xndq4iw8dg.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.39mnihrexbu7s8fu.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3bp08irize0ss86y.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3ewdn1tsahpuw1py.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3fwarc7rdvw95vty.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3hjk8am2okyqb9at.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3ntgx07lbti7oyhp.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3tni1w7qjc672ky3.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3xeqc7zaiijzchxj.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3zd86o6kxiwqsgq7.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.3zn8ovm9tgbbphjh.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.40c56ew1i5qdzj5.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.41f548983o9ina0d.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.41kb1b0e5td7ig1t.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.42n29y1jwi2tqwqc.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4634vlnfag6a7cuo.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4a19vf5mtk2uqrda.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4d18qx24gpk2fzqt.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4e8mio3ocljeidh0.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4hevinvfqods9a2z.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4oejtur50k7pqkcn.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4p3m0psmvdq3pbke.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4sddj5xejaax8ojs.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4snx54p2khyhwpjr.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4u47tnwfdto5ojba.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.4x41u5f1x1u4cq4f.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.52h3829j9qn41km2.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.598i0dsz7xhi3e56.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.5calrzdj1macsjzz.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.5f4p7ry25ofozm8o.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.5q89j3bvdv9rw5w.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.5x6e40uzapwjpm2.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.fxj2t4t988nljlr.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.go4ycywykh0q1v.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.kjq78t3we2m1hoa.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.npxsjf5zg8wnlzp.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.qcs86ujfch1s1hj.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.tzwyln95tyh2ma1.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.uvsmrlm0eooqg9o.rcgu.o" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.x31kd08uqej930d.rcgu.o" "-o" "/Users/home/code/jrsonnet/target/debug/deps/libjsonnet.dylib" "-Wl,-exported_symbols_list,/var/folders/6g/24kcslk14kn6t9f8p69wyd140000gn/T/rustcjaTXgk/list" "/Users/home/code/jrsonnet/target/debug/deps/jsonnet.52ptp9ps3jcx17lp.rcgu.o" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-nodefaultlibs" "-L" "/Users/home/code/jrsonnet/target/debug/deps" "-L" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/home/code/jrsonnet/target/debug/deps/libjrsonnet_evaluator-fbaa3b41554bc756.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libpathdiff-36ee8343c6e7cf48.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libbase64-6311ec00b7b3977f.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libmd5-0416bec9fcdf97c1.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libbincode-ee6db139e740030a.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libbyteorder-8236ddd56c636592.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libjrsonnet_stdlib-3d6a395c005f9164.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libannotate_snippets-4c125a1ff528a648.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libunicode_width-779ec376ac999ade.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libyansi_term-13e47990bb4aa2bf.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libindexmap-b399e378020de2b4.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libhashbrown-002261989edf6099.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libserde_json-1e2eec6248f5bd14.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libryu-4636ec5641c33604.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libitoa-9848dc7cd6694c00.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libclosure-299cd415411bc671.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libthiserror-e96c964f2d10553e.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libjrsonnet_types-e7a55706e41852d1.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libjrsonnet_parser-929a1536f828a49b.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libunescape-517684e2f845a2b4.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libpeg-08e6a412b8112cbf.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libpeg_runtime-5946167847eea76b.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libjrsonnet_interner-b006b07909e36b5f.rlib" "/Users/home/code/jrsonnet/target/debug/deps/libserde-0e2105f249ea355d.rlib" "/Users/home/code/jrsonnet/target/debug/deps/librustc_hash-81361b9a152cb103.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-518979da66993550.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-f52081aedccc205f.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libobject-bad1c02788187328.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libaddr2line-6375d8dbf53aee9d.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libgimli-0ea8539778b0c0ab.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_demangle-64f30c6d69babb18.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libhashbrown-e27428d997fd2532.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_alloc-f02467a76e5a8054.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libunwind-9536efad7116d828.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcfg_if-5ca171f6ec11d7a5.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-14b621861b38e51f.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-38f4a0c206512fa5.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_core-99bca6ace58141c5.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-72a66f4c97a4c0c8.rlib" "/Users/home/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-e7cd9f0beed2fc0f.rlib" "-lSystem" "-lresolv" "-lc" "-lm"
  = note: Undefined symbols for architecture x86_64:
            "__jrsonnet_static_native_callback", referenced from:
                _jrsonnet_apply_static_native_callback in jsonnet.1iyb5imdw1gd5st0.rcgu.o
            "__jrsonnet_static_import_callback", referenced from:
                _jrsonnet_apply_static_import_callback in jsonnet.1iyb5imdw1gd5st0.rcgu.o
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)
          

To reproduce:

Update: I get the same error on trying with f91abe0

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.