vrotaru

Good observation. Also there is some funny stuff with what the book say referenced appendices do and what those actually explain

At the end of chapter 30 we have:

   Next: Appendix A — OCaml Setup and Tooling

But the after the chapter 30, follows the chapter 31, and Appendix A is called

    Appendix A: Ocaml Quick Reference

And the link is a dead link.

This has strong vibes of "Do this and you will get rid of back pain" followed by the video of some crazy acrobatic stunt.

Congrats, BTW.

Here is my experience.

Claude did generated a rather good template for what I needed. It did not compile at first but I copy-pasted the errors and it fixed them.

Not all was good, though. It used literal bullets instead of `-` required for lists, but on whole the experience was positive.

It had taken me less time to fix the template than it would been taken to write it from scratch.

Something which Claude was good at. I throw him a crude ASCII "art" representation of what I want and get the right Typst code back.

Sorry for harping on it, but I think this clearly reflects the difference between 2 approaches to storing knowledge, lossy but humongous, and lossless but limited.

LLMs - Lossy highly compressed knowledge which when prompted "hallucinates" facts. LLMs hallucinations are simply how the stored information is retrieved.

Memory (human in this case) - Extremely limited, but almost always correct.

Just an observation. No morals.

There is a podman-compose which works almost as drop-in replacement.

Almost because most common commands work, but I have not check all.

And almost, because for some docker-compose.yaml which you downloaded/LLM generated you may need to prepend `docker.io/` to the image name

That is a good questions and I guess we have good progress since Plato whose definition was - A man is a featherless biped.

But I think we still do not know.

To some degree *all* LLM's answers are made up facts. For stuff that is abundantly present in training data those are almost always correct. For topics which are not common knowledge (allow for a great variability) you should always check.

I've started to think of LLM's as a form lossy compression of available knowledge which when prompted produces "facts".

Well, not exactly convince. I was curious what will happen.

If you are curious it was a question about the behavior of Kafka producer interceptors when an exception is thrown.

But I agree that it is hard to resist the temptation to treat LLM's as a pear.

You should always check. I've seen LLM's being wrong (and obstinate) on topics which are one step separated from common knowledge.

I had to post the source code to win the dispute, so to speak.

So what is your pick?

* AI is the next electric screwdriver * AI is THE steam engine.

My pick is that the AI is not THE steam engine.

> Oberon also doesn't seem to be actively developed anymore

That's pretty much it, for maybe 10+ years now. There was a successor project BlueBottle with some promise, but it did not deliver. Later it was renamed to A2. Surprisingly, it did not help.

https://en.wikipedia.org/wiki/A2_(operating_system)

IMO the authors of BB/A2 bet heavily on XML/Java hype, and were trying to make Oberon more like Java. The result was something without much internal consistency and not very usable.

Not being able to use a major browser and not having the resources to write one from scratch did not help either.

Then some of the major figures of this project left. And that was it.

There are some hobbyists and some small businesses which use it for niche projects and that is all

It happens. It shows you the right suggestion, and if you keep typing it assumes that you meant something else and displays other suggestion.

Good for slow typers, not so much for quick ones.

Maybe web.skype.com will be better? Just a guess.

Anyway, that's how I use Skype when I still have to use it. Which is about once a month.

The are LLVM Caleidoscope (toy compiler) in both Haskell and OCaml

https://github.com/sdiehl/kaleidoscope https://github.com/arbipher/llvm-ocaml-tutorial

The Haskell one is a nice one. Can say nothing about the OCaml one since I found it using a google search.

I've had a try at implementing an Caleidoscope compiler in OCaml but did not finish it. But it was fun to write.

I guess Modula-3 was doing it as well.

Records were structurally typed. But you can "braid"(?) a record and that will make it nominal type.

You know what else is self-cleaning?

   /dev/shm

The advantage being that it does not even touch the disk.

Just an example.

Should teachers be judged on how a pleasant life they live, or how good they teach?

Stop optimizing for consumers, start optimizing for producers.

Maybe, you want to rethink that.

lsattr - for reading attributes chattr - for setting them

You need the `i` attribute. But this is filesystem dependent. Anyway protecting the `sudo` binary from package managers is a so-so idea.

So, in order to write a new browser you first have to write (as a training exercise) a new OS.

Not the fastest way, but it seems to work. Best wishes to Andreas.

Guess so. Unfamiliar with Zig. The point is that not a "all or nothing" strategy for a compilation unit.

Debugger writers may not be happy, but maybe lldb supports all conventions supported by llvm.

There was an interesting aproach to this, in an experimental language some time ago

   fn f1 (x, y) #-> // Use C calling conventions

   fn f2 (x, y) -> // use fast calling conventions

The first one was mostly for interacting with C code, and the compiler knew how to call each function.

Well, I guess, that are islands of superconductivity and normal conductivity in the same sample.

This gives a low resistance and diamagnetism which is used as proxy to real superconductivity.

I may be wrong though.

That's just a sequence of commands

echo s .. # sync echo u .. # unmount echo b .. # reboot

Just a guess though

My beef is mostly with GTK3 and how it was introduced.

GTK4 seems to be better and at least it can be fast

There was no real reason to rush the transition to GTK3, but it was done anyway.

GTK3 with its half-assed support of CSS for theming is just just bad, and slow (especially on Macs)

And they continued to change GTK3 API after 3.0, which did not exactly help

Linux desktop will probably have more applications if there would have been less GTK versions.

Probably, but this is not enough. You also need to to have low expectations.

The web based reader will refuse to display some books, unfortunately.

In my case this was the sort of book than can be only realistically read on a big screen tablet, not on a Kindle.

Well, I've shrugged and downloaded the pdf from libgen

`fst` and `snd` possess a symmetry which `first` / `second` lack

Personally I've got used to them like in no time