auraham

> the agents didn't hack to find the answer to the problem; they hacked to try and figure out how the exploit gym evaluator worked so they could convince it they had solved the problem without doing so

Kobayashi Maru: Win a no-win situation by rewriting the rules -- Harvey Specter

I've been learning about React, Vue, and HTMX these days. As I understand, these tools aim to bring some level of interaction in a web application:

- Both React and Vue are all about reactivity: you have a variable, make it reactive by using something like ref() or useEffect(), and the framework will patch the DOM whenever that reactive variable changes. The idea is easy to understand but hard to implement. I agree with this podcast [1], where the author mentions that writing good React code is hard. I like Vue, but it is a bit overwhelming since it has many functions for creating reactive variables, like ref(), refs(), isRef(), unRef(), reactive(), toRefs(), computed(), etc [2].

- HTMX follows a similar idea: patching the DOM when an event occurs. Unlike React and Vue, HTMX does not rely on reactivity. Instead, it uses attributes like hx-get for requesting HTML fragments to the backend, patching the UI using those fragments. No watchers, no reactivity, just plain requests. This is (to some extend) suitable for dashboards, pagination, sorting tables, autocompletion. But if your application requires a higher level of interactivity, then React and Vue are a better option [2].

Then we have LiveView and Elixir, which I think is a better alternative/trade-off to these three tools:

- Similarly to React and Vue, LiveView has reactive variables (called assigns, you can think of it as a hashmap that holds the state of your application): every time the assigns changes, LiveView reloads the corresponding HTML fragment. This operation is efficient because LiveView knows which parts of the HTML fragment are static and which parts are dynamic. So when some variable changes, LiveView sends a tiny payload to the UI for updating the DOM.

- Also, LiveView follows an arguably simpler approach for reactivity, you only need to implement three functions: mount() to setup the initial state of the assigns, render() to prepare the HTML content, and handle_event() to handle events like button clicks or form submissions.

I think LiveView is so much easier to follow: if the assigns change, then the framework will update all the relevant HTML fragments. That's it. Also, we do not need to worry about adding third-party libraries for routing, state management, forms. Those are likely included in Phoenix.

[1] https://www.youtube.com/live/pMwTR2KeuaU?si=AU7sqxVwTv4lRhV6...

[2] https://youtu.be/k1TrnzZaygo?si=kCpMvOgB0Egk5mDg&t=380

I have the same feeling about Zig. In this interview [1], Andrew Kelley, creator of Zig, explains a lot of the features of the language; compares it against c, rust, go; and explains why he created the language. According to him, the killer feature of zig is the tool chain (compiler, linker, build system) since it has no dependencies. So, it will work in any OS/target you choose.

It is a really interesting interview. However, Zig code is a bit hard for me to read.

[1] https://www.youtube.com/watch?v=iqddnwKF8HQ&t=10s

Can you give more details about using zig along with elixir?

> microscope is mounted on a elixir nerves deployment!

What do you mean? I imagine that there is an Elixir application running on an embedded system and maybe it relies on an external binary application (compiled using zig). If so, how do you manage the communication between them?

> Tauri proved to be quite problematic except when in macOS

Can you elaborate?

For me, the best about Tauri is that:

- We can embed an existing application using a sidecar [1].

- Now, we can also use Elixir in the backend, embed the BEAM, and deliver a single binary, see ElixirKit [2].

As far as I know, LiveBook Desktop [3] is using Tauri for building binaries for MacOS and Windows. If Tauri works for the Elixir team, I think it works for me too.

Also, I know that Tauri is not bullet proof. WebView can be limited for some use cases, see [4]. There is some effort to use CEF to mitigate those problems, though [5].

I'd like to know how Deno Desktop compares with Tauri in this context. I know it is a new product, not sure if we could bundle an existing binary in Deno Desktop, like in ElixirKit.

[1] https://v2.tauri.app/develop/sidecar/

[2] https://elixirkit.hexdocs.pm/tauri.html

[3] https://github.com/livebook-dev/livebook/blob/main/rel/app/t...

[4] https://www.youtube.com/watch?v=vmslGvxObvM&t=621s

[5] https://github.com/orgs/tauri-apps/discussions/8524

I hope it stays the same for a long time

I gave it a try today using Linux Mint 22.3 with 16 GB of memory. Writing experience is OK, the UI is beautiful. However, when I load a medium markdown file (less than 200 lines), the UI is a bit slow. Scrolling and switching between two tabs take a lot of time. I tested after compiling it using `cargo tauri build`.

Interesting project! I will take a look at it.

Thanks for pointing that out.

Both uv and asdf can be compiled from source. I prefer that way.

This week I was wondering whether using uv for managing Python versions is a good idea.

From their website [1]

> Python does not publish official distributable binaries. As such, uv uses distributions from the Astral python-build-standalone project. See the Python distributions documentation for more details.

It points to this GitHub repo https://github.com/astral-sh/python-build-standalone which mentions this other link https://gregoryszorc.com/docs/python-build-standalone/main/r...

If I understand correctly, the source code for building Python is not fetched directly from python.org. Not so sure how secure is that.

I have the same concern for asdf [2]. However, they use pyenv [3] which, I think, feels more official.

Can someone clarify this? Which tool is better/more secure for installing python: uv or asdf?

[1] https://docs.astral.sh/uv/guides/install-python/

[2] https://github.com/asdf-community/asdf-python

[3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

I have the same concern with all hardware used for storing keys and secrets for crytpo.

How can you detect the system preferences in the browser?

Do you know what is the purpose of the staging build? Not sure why the author requires that flag when building the binary.

I highly recommend Build a large language model from scratch [1] by Sebastian Raschka. It provides a clear explanation of the building blocks used in the first versions of ChatGPT (GPT 2 if I recall correctly). The output of the model is a huge vector of n elements, where n is the number of tokens in the vocabulary. We use that huge vector as a probability distribution to sample the next token given an input sequence (i.e., a prompt). Under the hood, the model has several building blocks like tokenization, skip connections, self attention, masking, etc. The author makes a great job explaining all the concepts. It is very useful to understand how LLMs works.

[1] https://www.manning.com/books/build-a-large-language-model-f...

Can you explain how to build the installer? I pressume you bundle python and typescript in a single binary.

Can you elaborate on this? After skimming the README, I understand that "Who art Henry" is the prompt. What should be the correct 19th century prompt?

I gave it a try a few months ago. The first thing that I searched for was the REPL. Comparing it with Python, I prefer ipython over irb. It would be nice to see some improvement on DX on the REPL side

Updated revision (2022): https://nlp.seas.harvard.edu/annotated-transformer/

I was about to mention that.

Wonder if Wails have the same issue on Linux.

I thought this article was about using Rust for mobile development, like Tauri on Android.

Have you tried cocoindex?

[1] https://cocoindex.io/

[2] https://dev.to/cocoindex/how-to-build-index-with-text-embedd...

Can you elaborate on this? How is npm/cargo/etc better than pip on this regard?

As far as I know, files like requirements.txt, package.json, cargo.toml are intended to be used as a snapshot of the dependencies in your project.

In case you need to update dependency A that also affects dependency B and C, I am not sure how one tool is better than other.

I gave it a try a few months ago, but did not work for me. My main issue is that atuin broke my workflow with fzf (If I remember correctly, pressing ctrl + r to lookup my shell history did not work well after installing atuin).

I am aware of that option. However, AFAIK patching links do not prevent the user to press Back button.

Another advantage of using Elixir/Erlang/Phoenix is high availability. If one client/incomming requests is taking a lot of time to complete, other users are not affected. We can even inspect the system in real time via iex. Please search for "The soul of Elixir" in YouTube, Sasa Juric explains this. Highly recommended.

That is an interesting mix. Wonder if it is possible to send messages among Erlang VMs in different pods.

If Kubernetes is not involved, passing messages between Elixir nodes is easy. We just need the name of thr node (and a cookie, if needed).

Not sure if that is possible inside a Kube cluster.

Demos on youtube?