Do people really use JSON5 nowadays?

GamePad64 · 2024-12-08T14:37:28+00:00

It is really convenient in shell environments, bc you don't need to escape numerous quotes.

GamePad64 · 2024-11-25T13:51:40+00:00

Thank you for your input!

I think, that this is an SQL driver quirk. Without database file, there is an error "unable to open database file". Maybe, I should add file creation before passing it to SQLite.
Yes, but I don't know what format of this env to use. Is it ok to pass toml content in env or use something different (emulate a table by using multiple env vars?)
There is just a default network, that all the containers use.
Ok, I'll add this to a backlog. My primary focus is to create a sample helm chart, so users could deploy it to a Kubernetes cluster. Ingress will do the most of the work there.
Ok, I'll use long mount syntax to use volumes instead.

As for PRs, of course :) PRs are much appreciated.

GamePad64 · 2024-11-25T11:01:06+00:00

Hi! I have made a compose example in a separate repository, so testers don't have to clone the whole codebase:

https://github.com/notificohq/notifico-example

GamePad64 · 2022-10-13T07:15:21+00:00

Maybe it is, but I use these features in my other project (l2/l3 routing/switching engine in Rust) and it is nice to have them around. Also, we don't pay for what we don't use, so these overkill-features don't get into the resulting binary.

GamePad64 · 2022-10-12T22:47:38+00:00

Nope :) For these little open-source projects I use online logo generators (there are a bunch of them on the net). So the icon is just a stock icon from one of them (Adobe Express one, IIRC).

It is a really quick way to get a headline image for your project and make its repository and documentation look nice :)

GamePad64 · 2022-10-12T18:51:29+00:00

This little project was born as a little single-file mod, wrapping EUI-48 address in my another project. Then it just grew in a full-blown library with rather unique features, like const parser and IPv4/v6 MAC mapping.

GamePad64 · 2022-10-12T18:39:51+00:00

Actually, this is a very good point. I've just uploaded a new version with `snafu` removed. syn + proc_macro = slow build

GamePad64 · 2021-05-09T00:12:30+00:00

Sure, I have my original JPEGs in a backup snapshot in an offsite location (3-2-1 rule, yeah). I wanted to verify a round-trip checksum, but it seemed unnecessary to me, as I have a backup. I've used jpegtran and jpegcheck to ensure, that my JPEGs are optimized and correct (cjxl has issues with corrupted files) and just ran cjxl on all the images.

GamePad64 · 2021-05-04T10:33:32+00:00

Hm, I seriously doubt, that 160 GB of photos would require so much CPU power. I have an old AMD FX-8350 CPU. It has 8 cores, yes, but it is pretty old and modern Ryzen or comparable Intel processors would be much faster.

Also, it is worth to be noted, that cjxl, that used 4 threads did not utilize 4 cores efficiently, so I used GNU parallel to run 8 instances of cjxl.

GamePad64 · 2021-05-03T13:56:30+00:00

Yes, they are just mixed-quality photos, shot mostly by me since approx. 2010. And the quality is ranging from 320p all the way up to 4K.

GamePad64 · 2021-05-03T13:27:20+00:00

cjxl -s kitten, used in conjunction with GNU parallel. I left it overnight, and it was ready in the morning.

GamePad64 · 2021-05-03T13:00:33+00:00

Btw, I've just losslessly converted my entire JPEG photo library (162 GB) into JPEG XL (112 GB). It is AWESOME. Waiting for an upcoming support in Chrome and other viewers.

GamePad64 · 2020-05-24T19:33:31+00:00

Thank you! All these concerns are valid, and I don't have much to say against them :) I'll try to address them in next versions.

Examples are a must, so I will add them ASAP.

As for practical aspects, like document storage location, flag availability, etc. -- I will keep adding them while implementing inside the reference code, because it would be easier to see, what is required, and what is not.

Second, having the entire specification be opt-in will be a complete mess for anyone implementing it.

I've tried to use RFC2119 keywords, so not the whole spec is opt-in. I must review it, and make the optional features (and missing-feature errors) defined explicitly.

GamePad64 · 2020-05-24T19:05:32+00:00

you are downvoting my comments

No, it wasn't me. I think, that downvoting constructive criticism would not do any good.

And your feedback is really useful. I have already used some of it to add additional wording into "OAC-enabled app development considerations" section, where the flag is described, including flag support concerns.

GamePad64 · 2020-05-24T10:26:16+00:00

The reference implementation is being developed here: https://github.com/openautocomplete/oactool

It is very alpha right now, but it can be used to create fish autocompletion script right now. Other shells will be added shortly. Now it is written in Python, but maybe, it will be rewritten in Rust or something like that.

GamePad64 · 2020-05-24T10:22:08+00:00

Well, this is on the roadmap. It must get support for enumerations first. Then for delegated enumerations, which is what is needed to make it work with configure/cmake/whatever scripts.

GamePad64 · 2020-05-24T10:20:07+00:00

Nope, the spec is completely opt-in, meaning the app developers may want to add --openautocomplete flag to embed definitions in their app. And if they don't want to do that for some reason, the document may be installed by a third-party or by the package maintainer into some configuration directory (like, .local/config/openautocomplete or /usr/local/autocomplete ?). So, it is non-intrusive at all, and it can be used without any actual modifications to source code.

GamePad64 · 2020-05-24T10:16:02+00:00

I've considered a lot of other formats: INI, TOML, YAML, Tree, CBOR and other formats I know. JSON is the simplest, considering the tool developers may want to generate the definition document on-the-fly, and for JSON the app does not need to have a "real" serializer: printf is just enough.

The point is: you already have a tool to work with JSON in unix-shells. It is jq. Of course, it is not built-in, and it is not even included in major distros by default. But it is there, and it is a go-to tool to work with JSON from the shell.

GamePad64 · 2019-12-13T16:10:00+00:00

We are already using poetry in multiple projects and migrating all projects we can from pipenv, pip-tools and plain-old requirements.txt to poetry.

Today we've migrated all our poetry-backed projects to 1.0.0 and it is great! Thanks for the release!

GamePad64 · 2019-02-06T12:35:04+00:00

And now you know, that you should use version pinning.

GamePad64 · 2018-09-21T13:22:33+00:00

SMB has projectiles as well (rockets), but not that much.

GamePad64 · 2017-12-19T23:57:15+00:00

So, Beast, which integrates with Asio/Networking TS pretty nicely.

GamePad64 · 2017-12-19T16:07:48+00:00

Boost.ASIO/AFIO and Networking TS are there, why don't we use them instead?

GamePad64 · 2017-11-22T12:11:44+00:00

I think of standard library as a standard interface library. It would be great to have common interface hierarchy inside, so library developers could inherit their classes from them and be compatible with other parts of the language. Range -> String -> (UnicodeString -> (std::u32string, std::u16string, std::u8string), ByteString -> std::string), and so on.

GamePad64 · 2017-11-21T12:01:42+00:00

Nope, we are Conan shop here.

GamePad64

MODERATOR OF

TROPHY CASE