profile
viewpoint
Dave Cunningham sparkprime Google United Kingdom http://spark.woaf.net/

bazelbuild/rules_jsonnet 41

Jsonnet rules for Bazel

grit-engine/starbox 4

A utility for generating textures for rendering night skies in computer games based on real star data.

sparkprime/grit-engine 3

Grit Game Engine

GameBrian/zone-of-action 2

Mutliplayer First Person Shooter

grit-engine/high-freq-noise 2

A small utility to generate noise textures for PCF shadow mapping.

grit-engine/grit 1

High performance scriptable streaming open-world game engine, with realistic physics and graphics.

sparkprime/cloud-launcher 0

Simplifying launching apps on Google Cloud Platform.

sparkprime/CodeMirror 0

In-browser code editor

sparkprime/common_workflow_language_schema 0

Jsonnet documents for building a Common Workflow Language Avro protocol

issue commentgoogle/go-jsonnet

Consider contributing jsonnet to CNCF

Glad you like it :)

I wonder what concretely would change if it was part of the CNCF? And are there any bars to entry that would have to be met or something like that?

steeling

comment created time in a month

issue commentgoogle/go-jsonnet

request: `std.sha1`, `sha256`, and others

https://github.com/google/jsonnet/pull/607

ghostsquad

comment created time in 2 months

pull request commentgoogle/go-jsonnet

Anonymous Import Locations

LGTM

sbarzowski

comment created time in 2 months

pull request commentgoogle/go-jsonnet

Anonymous Import Locations

So I guess most importers probably just took dirname of the path, which is "" for both inputs "" and "<something>" so this is a pretty safe change?

sbarzowski

comment created time in 2 months

issue commentgoogle/jsonnet

Deprecate std.thisFile

I wonder if it would be more appropriate to provide separate file and path, and the path would always be absolute. That would go hand-in-hand with sandboxing file access according to a virtual filesystem created from the CWD and -J paths, and possibly some updates to the import handlers to separate the relative path resolution from the actual I/O. Just some thoughts.

sbarzowski

comment created time in 2 months

issue commentgoogle/go-jsonnet

go-jsonnet outputs different numbers compared to c++ jsonnet

Interesting, thanks. I remember we used to use --fpmath=sse to force the issue on x87.

mwu-ponyai

comment created time in 2 months

issue commentgoogle/go-jsonnet

go-jsonnet outputs different numbers compared to c++ jsonnet

Ok now I'm thinking I read it wrong and the standard actually does require everyone's cos() to behave. However I have definitely observed divergences between systems before!

mwu-ponyai

comment created time in 2 months

issue commentgoogle/go-jsonnet

go-jsonnet outputs different numbers compared to c++ jsonnet

Ok yeah it's more complicated than what I said. Some thoughts:

Intel 80 bit vs 64 bit is not actually an issue since we write all intermediate values to RAM. This is an issue if you have e.g. double x = 10; assert (x == 10) which is false for certain compilers.

-ffast-math also isn't an issue.

However the IEEE operations don't even include division I think? Certainly none of the complex ones based on taylor expansions, or whatever., since those are not just about representation but about how you explore the space to hone in on the answer, what lookup tables you use to accelerate it and stuff like that. Cos would fall into that category.

It may be that Go and C++ would be compatible on the same machine if Go uses the native math library. But I would expect C++ on e.g. intel / linux to be different to C++ on something more esoteric like AIX / power.

It's worth fixing specific issues to minimise the damage, but general compatibility is probably not possible.

mwu-ponyai

comment created time in 2 months

issue commentgoogle/go-jsonnet

go-jsonnet outputs different numbers compared to c++ jsonnet

This is unfortunately the great tragedy of building a hermetic configuration language based around floating point, which differs from system to system.

Different math libraries have different algorihtms with different performance / accuracy characteristics. Also different CPUs have different sized registers for floating point (or can be configured via flags that are set at the process level to change the floating point representation). IEEE only defines the format for the number itself, not the computation or the format of the intermediate values.

mwu-ponyai

comment created time in 2 months

push eventgoogle/jsonnet

Dave Cunningham

commit sha 9b5fdcb02e11cb8fd00f8b3fe130a12fdfca786d

The interface returns const char * from Python 3.7 onwards. This change is backwards compatible.

view details

push time in 2 months

PR merged google/jsonnet

const char* for Python 3 cla: yes

The interface returns const char * from Python 3.7 onwards. Our corresponding change is backwards compatible.

+4 -2

0 comment

1 changed file

sparkprime

pr closed time in 2 months

PR opened google/jsonnet

const char* for Python 3

The interface returns const char * from Python 3.7 onwards. Our corresponding change is backwards compatible.

+4 -2

0 comment

1 changed file

pr created time in 2 months

create barnchsparkprime/jsonnet

branch : fix_for_python_3.7

created branch time in 2 months

push eventsparkprime/jsonnet

Mike Danese

commit sha b9a74680726290ce2ae28c5dfb5716678b790761

throw error on shift with negative exponent Jsonnet spec: > Operators <<, >>, &, ^, | and ~ first convert their operands to signed > 64 bit integers, then perform the operations in a standard way, then > convert back to IEEE double precision floating point. ISO 9899:2011 6.5.7 Bit-wise shift operators: > The integer promotions are performed on each of the operands. The type > of the result is that of the promoted left operand. If the value of > the right operand is negative or is greater than or equal to the width > of the promoted left operand, the behavior is undefined. Jsonnet spec says jsonnet performs operations in "a standard way" which is not terribly specific. Alternatively, we could support negative shifts. Right now, my locally compile build just returns 0 for any negative shfit.

view details

Dave Cunningham

commit sha 29fd57097fba5bb9fa90038e855b1bd1ee0901c0

Fix floating point formatting, #799 (#801) * Fix floating point formatting, #799

view details

Jess Thrysoee

commit sha a6979e399ecd0e8d1091506201487a5c390d4d31

Fix clamp equivalent example in docs

view details

Stanisław Barzowski

commit sha 2a161cc0b49f26ecc20922981efdb4a8973f48d9

Add a formatter test for go-jsonnet issue 411.

view details

Stanisław Barzowski

commit sha 3f58aa551c917d6a7a2c6d042ee27f93d895ac0b

Release v0.16.0

view details

Cam Hutchison

commit sha 49fa2f56d017ff5ccfffe2585a67dd83d94d0f14

[Website] Fix docs for std.rstripChars From what looks like to be a cut-and-paste error, `std.rstripChars` is documented as removing chars from the beginning and end of a string, which should just be the end.

view details

Ben Brown

commit sha d75e953aafa1d5f79a7ea8c7f9863f2343a60a7e

Call python rather than version 2 explicitly

view details

Stanisław Barzowski

commit sha 4082284cdabbd037d49294ec8c0801c9fd81f696

[Docs] Generate stdlib docs with Jsonnet. Benefits: * Keeping things consistent should be easier. * We can now change the way it is represented in HTML without going over the whole thing. * We can now use the stdlib data programatically, so it should be easier to check it's in line with reality. * Make it easier to integrate with any potential documentation generation tools. * First step towards completely Jsonnet-based site generation which I think is worth exploring.

view details

Kasumi Hanazuki

commit sha 2da3e70355e09f85b2115c5a41489b41e30f493e

cmake: Specify INTERFACE include directories for libraries Specify INTERFACE include directories for the libraries so that the libraries' dependent targets can use the proper include directory automatically.

view details

Robert Vollmert

commit sha 0a134c9d52b4211a556d0b79214027ee82a046d2

Modify golden for reformatted golang tool help

view details

Stanisław Barzowski

commit sha cd73423536313f19655a10ca629df6690f19956d

Advertise go-jsonnet in README

view details

Stanisław Barzowski

commit sha a07561742d3c7d5b6ff2f27e7dd27f4c076f54c1

Add language reference (#831) This is not a complete reference yet, but it should be a solid base. It covers about ~50% of what I think it should ideally cover, but we have to start somewhere. I purposefully chose a fairly conversational, explanatory tone (for a language reference). We already have a more formal spec, so this is aimed more at users who want to understand some concepts better than at experts, who are interested in boundary cases.

view details

Stanisław Barzowski

commit sha ea4d40a0b4601cab148823459ba4d99f8841fe7a

Remove wrong information about comparing arrays Arrays cannot be currently compared with `<` and friends. I think we should fix it (#834), but in the meantime, we don't want to spread inaccurate information.

view details

Stanisław Barzowski

commit sha 2991580ddae4027384502cfe11a31bd032d58247

Fix spec errors pointed out in #804. This change only covers clear, simple errors and not stylistic issues or spec-implementation discrepancies.

view details

push time in 2 months

issue commentgoogle/go-jsonnet

How harmful can Jsonnet be?

Note that this is all pretty standard -- you'd want to do the same thing even with YAML because of things like https://en.wikipedia.org/wiki/Billion_laughs_attack

sh0rez

comment created time in 2 months

issue commentgoogle/go-jsonnet

How harmful can Jsonnet be?

Yeah you have it right. You should implement your own import handler to trap all I/O and sandbox it that way. Exec it from your server in a separate process in a ulimit jail, instead of just linking the library. That way you can bound its resource consumption and ensure that any crash does not affect other concurrent requests. Docker isn't necessary but you could use it.

sh0rez

comment created time in 2 months

issue commentsubsurface/subsurface

Subsurface-4.9.4-x86_64.AppImage -- Failed to claim the usb interface (LIBUSB_ERROR_BUSY)

I had a separate permissions issue that I "fixed" by changing the permission of /dev/usb/hiddev1 manually. Before doing that I got a different error, then I got this BUSY error instead. So definitely not permissions.

I haven't been able to get it working on android either. It detects the dive computer but then doesn't download anything when I click download.

darrell-barabash

comment created time in 2 months

issue commentsubsurface/subsurface

Subsurface-4.9.4-x86_64.AppImage -- Failed to claim the usb interface (LIBUSB_ERROR_BUSY)

I got this on chromebook and Ubuntu for a Suunto D5. Also using the appimage. Is it a workaround to use another release (not appimage)? I'm guessing the appimage was built against a buggy libusb or something like that?

darrell-barabash

comment created time in 2 months

issue commentgoogle/jsonnet

Deprecate std.thisFile

@gotwarlost You could probably use an import handler instead of a native function for that

sbarzowski

comment created time in 2 months

more