tracnar

It also supports .tar but that's probably not very commonly used.

Haha indeed. At work suddenly documentation and APIs are important, but it's all for/behind "skills". Before it was always "sure, that would be nice"...

I do welcome the improvements to doc and APIs this brings though!

Could you have a heuristics based on the input size and the pattern to decide what to use?

They do, but the US can still force them to hand over data that's in EU. (This was confirmed by Microsoft France officials.)

At least in Belgium it's quite common for a lot of students to fail the first year (partly due to the difficulty, partly due to partying instead of studying). But it's not like it's really free, the tuition is cheap but the accomodation is expensive. I also don't think it's particularly difficult on purpose to filter out students, it's just that it's not overly expensive and a lot of people are unsure about what to study.

If you're porting a library, you can use the original implementation as an 'oracle' for your tests. Which means you only need a way to write/generate inputs, then verify the output matches the original implementation.

It doesn't work for everything of course but it's a nice way to bug-for-bug compatible rewrites.

Indeed, the Tcl implementation does this so e.g. `set d [dict] ; dict set d key value` can modify d in place instead of creating a copy (since everything is immutable).

You could use this funky tool from oss-rebuild which proxies registries so they return the state they were at a past date: https://github.com/google/oss-rebuild/tree/main/cmd/timewarp

There's Hedy if you want to try a text based programming language for kids: https://www.hedy.org/

What actually happens if you remove read permissions on the /nix/store directory? Do things still work? I suppose I'll need to try!

I wish a Python package manager would support patching dependencies, like e.g. Cargo allows: https://doc.rust-lang.org/cargo/reference/overriding-depende...

It's much cleaner than monkey patching, and it will more likely detect if an update conflicts with your patching.

I've used it by packaging everything through nix, but that can be cumbersome.

Don't you need to wait for some kind of delimiter (like ",", "]", "}", newline, EOF) before parsing something else than a string?

For optimizing the module finding, using a custom import hook was indeed what I had in mind!

While I see the usefulness of lazy imports, it always seemed a bit backward to me for the importer to ask for lazy import, especially if you make it an import keyword rather than a Python flag. Instead I'd expect the modules to declare (and maybe enforce) that they don't have side effects, that way you know they can be lazily imported, and it opens the door for more optimizations, like declaring the module immutable. That links to the performance barrier of Python due to its dynamic nature as discussed in https://news.ycombinator.com/item?id=44809387

Of course that doesn't solve the overhead of finding the modules, but that could be optimized without lazy import, for example by having a way to pre-compute the module locations at install time.

I've always thought it would be great for the government to provide a free domain name for every citizen. There's really not much you can do without DNS.

For logic in Python this project looks pretty neat, it encodes facts as typed objects and rules as functions, then allows you to run the model using a solver like soufflé: https://py-typedlogic.github.io/

I haven't found an excuse to really use it though!

I was always surprised that NixOS doesn't have a better story there, the main install instructions are to do manual partitioning, generate a config, edit it, etc. What I had expected at first would be that you'd write the config first and then deploy it, like in the article. But even with the method presented here you have the imperative step of running nixos-anywhere. Having something like the ignition system of Fedora CoreOS where you'd point at an existing config and it would install everything would make more sense IMO. Or pre build an iso which installs itself.

I was also thinking about this use case when reading the announcement. Let's say you have a bunch of parquet files already (on local FS, HTTPS, S3, ...) that you can assume are immutable (or maybe append-only). It would be great if you could attach them to the DuckLake without copying them! From the design doc, it seems it should essentially work, you would read those parquet files to compute the metadata, and insert a reference to the parquet file instead of copying them to the storage you manage. Basically you want to create the catalog independently from the underlying data.

True, I believe I mostly worked around that limitation by splitting off quoted from unquoted code into separate commands. So in your example "[cmd $bar]" would be in a separate unquoted command, probably putting it in a temporary variable, which can cause problems as it's hard to have a private scope when doing metaprogramming. You can also use "[list]" in the middle of code, but it gets more error prone, for example "set foo \[[list cmd \$bar]\]"

For sure there is a lack of proper "code as data" constructs in Tcl, like you would find in Lisp.

I implemented something very similar a while ago, it's indeed too bad it's not built-in. I don't think you need such a "quasiquote" function, [list {*}$args] can escape a single command, and then it's a matter of joining multiple commands using a newline. IIRC that's how I did it.

I also had further fun with wrapping "proc" by implementing a "pyproc" which called out to Python while looking like a normal Tcl proc.

That's actually how the nix package manager works, normal users can 'install', or even build, packages. It works because the installation does not really have any side effects beyond using some resources (disk space, network, CPU), which as you point out you could anyway use as a normal user.

Agreed. Also if you can generate your configuration at build time, it matters much less whether you use a Turing complete language or not. It then allows you to enforce limitations you care about, like e.g. forbidding network access, or making sure it builds within X seconds.

Or go even further and you get yaml?

Interesting! A use case I could see for using builtins would be to gradually rewrite a bash script in some other language, as otherwise you have to do it through subprocess which can be slow and inconvenient.

Nice! I tried using XQuery (superset of XPath 3) for a while through the BaseX implementation. It's pretty nice, but you have to face XML problems like namespaces, document order, attributes vs nodes, you don't know if you can have 0, 1 or more nodes, etc. Something I wish was more readily available would be to run XPath against JSON, yaml, etc. It's a nicer language than say jq, but its ties to XML sometimes make it hard to transfer.

Another pain point with XML is the lack of inline schema, so the languages around like XPath have to work with arbitrary structures unlike say JSON where you at least have basic primitives like map/dict, numbers, bool, etc

The unison programming language does foray into a truly distributed programming language: https://www.unison-lang.org/

Ok great, I indeed just tried, I might just have been confused last time! Maybe you could mention in the doc that a module can be a "package"? (Even though I suppose a package is also a module, I always find the Python terminology a bit confusing there.)

When I tried it, it seemed like you really need to list all modules in `tach.toml`.

What I wanted was to work at a coarser package level. For example if you have the modules `foo.a`, `foo.b`, `bar.a`, and `bar.b`, I'd like a rule that `bar` can import from `foo` but not vice versa, without having to list or care about the submodules.

Is that something you'd want to support?

I agree that "reproducible builds" now means something different, but that isn't exactly the fault of Nix advocates. I guess a new term for "being able to repeat the same build steps with the same inputs" is needed.

I've usually seen "repeatable builds" used for that.

To be clear I did not make CrossHair.

I was also looking into it to turn normal python functions into some kind of constraints. But as you point out in your article it cannot really work through python imperative statements like conditions and loops, so you either need to find a way to cover all code paths, or only use a subset of Python (like Z3 does to some degree I believe). I still need to try it out further.

For your proof assistant it seems you could indeed use it if you limit yourself to Python expressions. Interesting stuff!