_flux

There are the commands git request-pull and git send-email to work with that workflow, though.

Frankly I don't think one even needs to learn it, if you know a bunch of other languages and the codebase is good. I was able to just make a useful change to an open source project by just doing it, without having written any lines of Go before. Granted the MR needed some revisions.

Rust is my favorite, though. There are values beyond ease of contribution. I can't replicate the experience with a Rust project anymore, but I suspect it would have been tougher.

Keyboard arrows worked.

But this method is now spent, as if someone is determined on keep using LLM, this should be pretty easy to overcome.

I suppose though new methods could be devised, but it's not "certainty" that they will catch them.

It doesn't seem the actual serialization format is specified? Other than in the code that is.

Is it versioned? Or does it need to be..

And as I understand it, most (if not all) of these segfaults were in casual use, not when someone is trying to attack it..

Wow, I thought you were exaggerating, but no: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

Open 80, closed 492.

I got myself a NUC. It's been worth it: tiny, has 16 GB of memory and 504 days of uptime.

I have servers for running VMs and containers but I felt like it would be nice to have this one as a separate device. It's also easy to plug in radio devices.

Quoting my original message:

> And why do we not anymore make use of it, but instead implemented separate JSON loading functionality in JavaScript?

In other words: I'm asking for reasons why was native JSON JavaScript module created, if we already had eval.

> Can you think of any reasons beyond performance?

One of the reasons is that native JSON parser is faster than eval: give some other reason.

To me, this is the first time Wayland feels like it's not a waste of time. The display server does not need to have the complexity of window managing on top the surface management. I certainly share the author's sentiment:

> Although, I do not know for sure why the original Wayland authors chose to combine the window manager and Wayland compositor, I assume it was simply the path of least resistance.

Although I'm not sure if it was the least resistance per se (as a social phenomenon), but just that it's an easier problem to tackle. Or maybe the authors means the same thing.

(That and the remote access story needs to be fixed. It just works in X11. Last time I tried it with a system that had 90 degree display orientation, my input was 90 degrees off from the real one. Now, this is of course just a bug, but I have a strong feeling that the way architecture Wayland has been built makes these kind of bugs much easier to create than in X11.)

I actually gave it some thought. I had written the actual reason first, but I realized that the person I was responding to must know this, yet keeps arguing in that eval is just fine.

I would say they are arguing that in bad faith, so I wanted to enter a dialogue where they are either forced to agree, or more likely, not respond at all.

I mean if you don't have sight.

Arguably them being in Unicode is an accessibility issue, unless we thought to standardize GIF names, and then that already sounds a lot like Unicode.

And why do we not anymore make use of it, but instead implemented separate JSON loading functionality in JavaScript? Can you think of any reasons beyond performance?

I've found it nice to have the terminal emulator be able to match text with regexp and upon a click convert it to an external action. For example, I can click Python traceback in terminal and have Emacs go into that exact line in code, or the JIRA issue id and go to the web page.

I wonder though if this is a popular feature. Tilix is under minimal maintenance at the moment, so alternatives would be good to have..

I'm sure models predicting how their body changes (based on various parameters and previous scans of the particular person and other people) could be built, allowing to optimize for longest time period of "decent fit" at the cost of "perfect fit now".

As I understand it, a big part of produced clothing just goes straight to waste to begin with. If everything was created on-demand, it would minimize that kind of waste.

Actually I've read claims that ESP32 C6s are pretty decent battery-consumption-wise. So much so that I bought a few, hoping to make at least a doorbell out of it. Alas I don't have a device to measure microampers, so I guess I'll just see how long they're fare..

The top-level README gives a bit better idea. Armed with that the explanation might sound a bit more understandable.

I'm not familiar with the project (or Clojure), but let me try to explain!

> Mycelium structures applications as directed graphs of pure data transformations.

There is a graph that describes how the data flows in the system. `fn(x) -> x + 1` in a hypothetical language would be a node that takes in a value and outputs a value. The graph would then arrange that function to be called as a result of a previous node computing the parameter x for it.

> Each node (cell) has explicit input/output schemas.

Input and output of a node must comply to a defined schema, which I presume is checked at runtime, as Clojure is a dynamically typed language. So functions (aka nodes) have input and output types and presumably they should try to be pure. My guess is there should be nodes dedicated for side effects.

> Cells are developed and tested in complete isolation, then composed into workflows that are validated at compile time.

Sounds like they are pure functions. Workflows are validated at compile time, even if the nodes themselves are in Clojure.

> Routing between cells is determined by dispatch predicates defined at the workflow level — handlers compute data, the graph decides where it goes.

When the graph is built, you don't just need to travel all outgoing edges from a node to the next, but you can place predicates on those edges. The aforementioned nodes do not have these predicates, so I suppose suppose the predicates would be their own small pure-ish functions with the same as input data as a node would get, but their output value is only a boolean.

> Mycelium uses Maestro state machines and

Maestro is a Clojure library for Finite State Machines: https://github.com/yogthos/maestro

> Malli contracts

Malli looks like a parsing/data structure specification EDSL for Clojure: https://github.com/metosin/malli

> to define "The Law of the Graph," providing a high-integrity environment where humans architect and AI agents implement.

Well, beats me. I don't know what is "The Law of the Graph" and Internet doesn't seem to know either. I suppose it tries to say how you can from the processing graph to see that given input data to the ingress of the graph you have high confidence that you will get expected data at the final egress from the graph.

I do think these kind of guardrails can be beneficial for AI agents developing code. I feel that for that application some additional level of redundancy can improve code quality, even if the guards are generated by the AI code to begin with.

That's not lower power, is it? E.g. RuuviTags can run 3 years or longer while sending sensor data 2.5 times per second, with a single CR2477 (3V 1000mAh). A single AA alkaline battery has 1.5V and 2100-2700 mAh (https://batteryskills.com/aa-battery-comparison-chart/ , somehow this data was difficult to find so I'll add this link :)).

Bluetooth is lower energy than WiFi, but in your scenario the energy used for the radio is quite low anyway.

I did a similar thing a while back: https://github.com/eras/midihidi

While that one might not be of much use, yours might be :). Actually I just have a small midikbd next to my computer, so maybe I could find use for this.

I did think of one potential use for midihidi: using MIDI as input device when running a tracked in an Amiga emulator.

Hm, what is preventing from putting more than one query into the same file?

Well initially it was a lot less capable. Someone might describe it auto-complete on steroids.

Someone might call LLMs that today, except they've stepped a bit up from steroids.

You can put more than one function in one file.

Write the binary to a file, call it `libquery-id1234.so`, and link that to whichever processes that need it?

I think it would be interesting to include it in the comparison table, as I think it could be viewed as a base line language-aware merge tool.

How does it compare to https://mergiraf.org/ ? I've had good experience with it so far, although I rarely even need it.

It's also based on treesitter, but probably otherwise a more baseline algorithm. I wonder if that "entity-awareness" actually then brings something to the table in addition to the AST.

edit: man, I tried searching this thread for mention of the tool for a few times, but apparently its name is not mergigraf

> The problem with LLM for me is that it is now possible to write anything using only assembly. While technically possible, who can possibly read and understand the mountain of code that it is going to generate?

As a very practical problem the assembly would consume the context window like no other. And another is having some static guardrails; sometimes LLMs make mistakes, and without guard rails it debugging some of them becomes quite a big workload.

So to keep things efficient, an LLM would first need to create its own programming language. I think we'll actually see some proposals for a token-effective language that has good abstraction abilities for this exact use.

Hm, how does one not get into that conclusion? Most everyone would agree we have the concept of "selfness", yet I don't think there's a scientific theory to explain how a set of physiochemical processes can have that endresult to an observer, any more than a computer has the idea of "me".

FreeCAD relies on OpenCascade kernel to actually deal with the models, and yes, there's still room for improvement..

As I understand it, there are no other open source alternatives around. On the commercial side there are some, perhaps the foremost being the venerable Parasolid, which is used by Onshape, Solid Edge, Solid Works, Siemens NX, Shapr 3d and others.

Creating a solid 3d kernel is hard. Parasolid is from 1986.