specifications
jc
specifications | jc | |
---|---|---|
6 | 96 | |
9 | 7,573 | |
- | - | |
4.1 | 9.5 | |
4 months ago | 2 days ago | |
HTML | Python | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
specifications
-
SVGs as Elm Code
Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children.
I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/spec...
Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets.
It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility.
BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.
-
Jc – JSONifies the output of many CLI tools
A plain Jevko parser simply turns your unicode sequence into a tree which has its fragments as leaves/labels.
No data types on that level, much like in XML.
Now above that level there is several ways to differentiate between them.
The simplest pragmatic way is a kind of type inference: if a text parses as a number, it's a number, if it's "true" or "false", it's a boolean. Otherwise it's a string. If you know the implicit schema of your data then this will be sufficient to get the job done.
Otherwise you employ a separate schema -- JC in particular has per-parser schemas anyway, so that's covered in this case.
Or you do "syntax-driven" data types, similar to JSON, e.g. strings start w/ "'".
Here is a shitty demo: https://jevko.github.io/interjevko.bundle.html
It shows schema inference from JSON and the schemaless (syntax-driven) flavor.
Jevko itself is stable and formally specified: https://github.com/jevko/specifications/blob/master/spec-sta...
It's very easy to write a parser in any language (I've written one in several) and from there start using it.
However, I am still very much working on specifications for formats above Jevko. I have some recent implementations of the simplest possible format which converts Jevko to arrays/objects/strings:
* https://github.com/jevko/easyjevko.lua
-
Jevko: a minimal general-purpose syntax
Thank you for your feedback. Can you clarify?
What is the "first page" that you are referring to?
Can you paste a link to it along with the broken examples link?
This Hacker News submission features the blog post under this URL:
https://djedr.github.io/posts/jevko-2022-02-22.html
Clearly, you are not talking about this page, as that contains multiple links rather than a singular link.
Perhaps you are talking about the specification which is here:
https://github.com/jevko/specifications/blob/master/spec-sta...
(linked from the blog post)
and here:
https://jevko.org/spec.html
(linked from jevko.org)
All three link to Jevko examples here:
https://github.com/jevko/examples
but all these examples links seem to be correct on my end.
I agree about the importance of examples, and I try to lead with them on jevko.org and jevko.github.io (which are the front pages of Jevko -- possibly I should merge them into one).
However a formal specification is not necessarily the place to put the leading examples.
This is also where the Subjevko rule is defined. It isn't quite introduced as "known knowledge" -- the purpose of a specification is to define the unknown, more or less from the ground up. This is also why specifications tend to get a little abstract. Jevko's spec is no exception. This should be in line with expectations of authors of tools such as parsers, validators, generators, or other kinds of processors, for which the spec is the authoritative reference.
It is not necessarily the best first place to look for explanation, if you are approaching from a more casual side.
I agree that from that side a clear picture of what Jevko is and how it can be used is still lacking. I certainly should add more examples and explain the concepts with analogies.
So I appreciate the essence of your advice and hope I'll manage to improve on that.
- Syntax Design
jc
-
Xonsh: Python-powered, cross-platform, Unix-gazing shell
https://github.com/kellyjonbrazil/jc - "CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and simplifying automation scripts."
-
Gooey: Turn almost any Python command line program into a full GUI application
> I'd love to see programs communicate through a typed JSON/proto format that shed enough details to make this more independent, and get useful shell command structuring/completion or full blown GUIs from simply introspecting the expected input and output types.
You should try PowerShell. It's basically Microsoft's .NET ecosystem molded into an interactive command line. I'm not entirely sure if PoweShell can make full use of the static types that build up its core, but its ability to exchange objects in the command line is almost unmatched.
On Linux you can use `jc` (https://github.com/kellyjonbrazil/jc) combined with `jq` (https://jqlang.github.io/jq/) to glue together command lines.
- jc: Converts the output of popular command-line tools to JSON
- why does the proc directory exist?
- Open source python projecto to contribute to
-
jq 1.7 Released
In addition to my previous comment about jq-like tools, I want to share a couple other interesting tools, which I use alongside jq are jo [0] and jc [1].
[0]: https://github.com/jpmens/jo
[1]: https://github.com/kellyjonbrazil/jc
-
The Case for Nushell
> I wanted to write some wrappers for the standard commands that automatically did all this via `jq`.
If you're not already aware of it, you may wish to check out `jc`[0] which describes itself as a "CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq..."
The `jc` documentation[1] & parser[2] for `ls` also demonstrates that reliable & cross-platform parsing of even "basic" commands can be non-trivial.
[0] https://github.com/kellyjonbrazil/jc
[1] https://kellyjonbrazil.github.io/jc/docs/parsers/ls
[2] https://github.com/kellyjonbrazil/jc/blob/4cd721be8595db52b6...
What are some alternatives?
binary-experiments - Experiments with various binary formats based on Jevko.
jq - Command-line JSON processor [Moved to: https://github.com/jqlang/jq]
mint-lang - :leaves: A refreshing programming language for the front-end web
jq - Command-line JSON processor
easyjevko.lua - An Easy Jevko library for Lua.
murex - A smarter shell and scripting environment with advanced features designed for usability, safety and productivity (eg smarter DevOps tooling)
algebralang - at this time this is some example code of a language I want to build
jello - CLI tool to filter JSON and JSON Lines data with Python syntax. (Similar to jq)
tree - A Data Modeling Programming Language
babashka - A Clojure babushka for the grey areas of Bash (native fast-starting Clojure scripting environment) [Moved to: https://github.com/babashka/babashka]
yapl - YAml Programming Language
Octo Pack - Creates Octopus-compatible NuGet packages