tracnar
Joined 197 karma
- 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://www.hackerneue.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
It doesn't work for everything of course but it's a nice way to bug-for-bug compatible rewrites.