tinycc VS bu

A better solution is just to write a plain ass shell script that tests if various C snippets compile.

https://github.com/oilshell/oil/blob/master/configure

https://github.com/oilshell/oil/blob/master/build/detect-pwe...

Not an unholy mix of m4, shell, and C, all in the same file.

---

These are the same style as a the configure scripts that Fabrice Bellard wrote for tcc and QEMU.

They are plain ass shell scripts, because he actually understands the code he writes.

https://github.com/qemu/qemu/blob/master/configure

https://github.com/TinyCC/tinycc/blob/mob/configure

OCaml’s configure script is also “normal”.

You don’t have to copy and paste thousands of lines of GNU stuff that you don’t understand.

(copy of lobste.rs comment)

I can highly recommend libtcc (https://github.com/TinyCC/tinycc.git) for this kind of thing. I recently ported the code developed in linux on an ARM chromebook to a generic windows box in 20 minutes.

I think it's a pretty nice prog.lang. You may be very happy. Though nothing is perfect, there is much to recommend it. By now I've written over 150 command-line tools with https://github.com/c-blake/cligen . A few are at https://github.com/c-blake/bu or https://github.com/c-blake/nio (screw 1970s COBOL-esque SQL) or in their own repos.

If it helps, I like to use the "mob branch" [0] of TinyCC/tcc [1] for really fast builds in debugging mode, but this may only work if you toss `@if tcc: mm:markAndSweep @end` or similar in your nim.cfg. Then I have a little `@if r: ...` so I can say `nim c -d:r foo` for a release build with gcc/whatever.

[0] https://repo.or.cz/w/tinycc.git

[1] https://en.wikipedia.org/wiki/Tiny_C_Compiler

I have found the libtcc from https://github.com/TinyCC/tinycc to be absolutely fantastic. I'm using it to instantaneously compile the C output from my hobby language to create a repl. Once I had the compiler in good shape it allowed me to create a 100% compatible interpreter for (basically) free.

The libtcc API is minimal. For my needs that has been 100% sufficient and a pleasure to work with.

The latest version that people are working with can be found on the 'mob' branch at https://repo.or.cz/w/tinycc.git

Instead of interpreters, if one has less of a "must be a full featured prog.lang" mentality and a fast compiler like Go or Nim [1] (or is willing to wait, for slow optimizing compiles to apply against big data sets) then an end-to-end simpler design for "one-liners" (or similarly simple programs) is the whole program generator. Maybe "big IFs", but also maybe not.

To back up my simplicity claim, consider rp [2] -- like 60 non-comment/import/signature lines of code for the generator. Generated programs are even smaller. But, you can deploy gcc or clang or whatever against them and make fast libraries in the host language.

Why, if you are willing to write those little generation command options in C99 then you can compile the harness with tcc [3] in about 1 millisecond which is faster than most interpreter start-up times - byte code or otherwise - and can link against gcc -O3 (or whatever) helper libraries.

Anyway, I only write this because in my experience few people realize how much development cost they buy into when then insist on a full featured prog.lang, not to criticize Ben's work. You also make users need to learn quirks of that new language instead of the quirks of a "harness" which may be fewer.

[1] https://forum.nim-lang.org/

[2] https://github.com/c-blake/cligen/blob/master/examples/rp.ni...

[3] https://repo.or.cz/w/tinycc.git

I think it is. At least there have been some recent activity in https://repo.or.cz/w/tinycc.git

I think Nim is great for small CLIs. Some examples are over at: https://github.com/c-blake/bu . To quantify "small", using tools themselves in bu/ (and Zsh *):

    wc -l --total=never **.nim|cols 1|cstats ms q.05 q.95

200 lines of Nim [1] seems to run about 9X faster than the 8000 lines of C in fdupes on a little test dir I have. If you need C, I think jdupes [2] is faster as @TacticalCoder points out a couple of times here. In my testing, `dups` is usually faster than `jdupes`, though.

[1] https://github.com/c-blake/bu/blob/main/dups.nim

[2] https://github.com/jbruchon/jdupes

You better off with using a compiled language.

If you interested in a language that's compiled, fast, but as easy and pleasant as Python - I'd recommend you take a look at [Nim](https://nim-lang.org).

And to prove what Nim's capable of - here's a cool repo with 100+ cli apps someone wrote in Nim: [c-blake/bu](https://github.com/c-blake/bu)

20 milliseconds? On my 7 year old Linux box, this little Nim program https://github.com/c-blake/bu/blob/main/wsz.nim runs to completion in 275 microseconds when fully statically linked with musl libc on Linux. That's with a stripped environment (with `env -i`). It takes more like 318 microseconds with my usual 54 environment variables. The program only does about 17 system calls, though.

Additionally, https://github.com/c-blake/cligen makes decent CLI tools a real breeze. If you like some of Go's qualities but the language seems too limited, you might like Nim: https://nim-lang.org. I generally find getting good performance much less of a challenge with Nim, but Nim is undeniably less well known with a smaller ecosystem and less corporate backing.

Often whole program generation in a prog.lang (& ecosystem!) that you already know can substitute for a new prog.lang. Python even has eval. You may be interested in: https://github.com/c-blake/bu/blob/main/doc/rp.md

You can actually get pretty far depending upon boundaries with the always implicit command-option language (when launched from the shell language, anyway). For example, Ben's example can be adapted to:

    rp -m^\[A-Za-z\] 'echo nr," ",s[1]'

You might consider: https://github.com/c-blake/bu/blob/main/doc/cols.md

That's in Nim, though that may not be much a barrier. (There may also be other tools in bu/ of interest.)

This sounds like a job for what standard C calls "popen". You can do `import posix; for line in popen("ls", "r"): echo line` in Nim, though you obviously need to replace `echo line` with other desired processing and learn how to do that.

You might also want to consider `rp` which is a program generator-compiler-runner along the lines of `awk` but with all the code just Nim snippets interpolated into a program template: https://github.com/c-blake/bu/blob/main/doc/rp.md . E.g.:

    ls -l | rp -pimport\ stats -bvar\ r:RunningStat -wnf\>4 r.push\ 4.f -eecho\ r

Nim is terse yet general and can be made even more so with effort. E.g., You can gin up a little framework that is even more terse than awk yet statically typed and trivially convertible to run much faster like https://github.com/c-blake/bu/blob/main/doc/rp.md

You can statically introspect code to then generate related/translated ASTs to create nearly frictionless helper facilities like https://github.com/c-blake/cligen .

You can do all of this without any real run-time speed sacrifices, depending upon the level of effort you put in / your expertise. Since it generates C/C++ or Javascript you get all the abilities of backend compilers almost out of the box, like profile-guided-optimization or for JS JIT compilation.

I don't know about all your other questions, but the https://github.com/c-blake/cligen CLI framework seems much lower effort / ceremony than even Rust's `argh` and is just about as old as `clap` (both started 8 years ago in 2015).

There are over 50 CLI utilities at https://github.com/c-blake/bu, many of which do something novel rather than just "re-doing ls/find/cat with a twist". While they are really more an "ls/ps construction toolkits" with some default configs to get people going, I think https://github.com/c-blake/lc and https://github.com/c-blake/procs are nicer than Rust alternatives. I mention these since you seem interested in such tools.

You are welcome. Thanks are too rarely offered. :-)

You may also be interested in word stemming ( such as used by snowball stemmer in https://github.com/c-blake/nimsearch ) or other NLP techniques, but I don't know how internationalized/multi-lingual that stuff is, but conceptually you might want "series of stemmed words" to be the content fragments of interest.

Similarity scores have many applications. Weights on graph of cancelled downloads ranked by size might be one. :)

Of course, for your specific "truncation" problem, you might also be able to just do an edit distance against the much smaller filenames and compare data prefixes in files or use a SHA256 of a content-based first slice. ( There are edit distance algos in Nim in https://github.com/c-blake/cligen/blob/master/cligen/textUt.... as well as in https://github.com/c-blake/suggest ).

Or, you could do a little program like ndup/sh/ndup to create a "mirrored file tree" of such content-based slices then you could use any true duplicate-file finder (like https://github.com/c-blake/bu/blob/main/dups.nim) on the little signature system to identify duplicates and go from path suffixes in those clusters back to the main filesystem. Of course, a single KV store within one or two files would be more efficient than thousands of tiny files. There are many possibilities.