A genuine question: is the first point (flow typing / type narrowing) a subset of or intersection with or just an alias to SSA (static single assignment)? I'm playing with a small interpreted language implementation that is based on Lua, and have reached a point where I want to implement a single-pass SSA (there is a nice short CS paper on this), but cannot get my head around all the concepts, even if I need proper SSA for Typescript-like usability.
No. Type systems are unrelated to abstract machines which are unrelated to usability.
Type inference/checking happens early in the pipeline.
SSA is a way of laying out assembly instructions for an abstract machine. I say abstract because real machines re-assign values to the same addresses over time (which is precisely what 'single' static assignment prescribes against). Once you know which registers your real machine has (and instructions), you could take your SSA and turn it into real assembly.
Also, "single-pass SSA"? Not to be too pedantic, but SSA is the destination, not the journey. You could take a single pass to transform from some expressions or statements into SSA, or perhaps from SSA into something else. What's the paper?
My idea was that with single pass, I can build SSA form during AST construction, and use phi-nodes to update type flow info. Then I could use SSA form to prove that I can use certain optimized bytecode instructions when a variable/register is known to be of certain type (I have virtual registers and fat instructions, eg ADD takes 2 sources and destination). Maybe I'm mixing control flow, type flow and SSA. I do not understand where I should stop with the pipeline if I use bytecode/VM.
The paper is: Brandis, Marc M., and Hanspeter Mössenböck. "Single-pass generation of static single-assignment form for structured languages." (https://bernsteinbear.com/assets/img/brandis-single-pass.pdf). It was quite understandable to me. For a deeper dive with proper SSA construction with dominance frontiers I could not find time to dig deeper, many other papers on SSA require focused CS work on them, not practically feasible for a side project. Also, single-pass is a requirement for very fast compilation to bytecode and LSP feedback.
I tried to read TS and Pyright source code, they share the same style of immense files and nested local functions, that was quite a steep wall to understand actual inner workings in detail. Maybe TS implementation in Go will be easier to read, it's on my later TODO list. It's tempting to use AI for help, but I'm quite experienced already with undoing AI work when it takes a wrong direction and I do not notice early.
Yep, this sounds like conflating two different ideas about SSA.
You could parse a source language with shadowed variables into an AST, and then one of your earliest AST transforms could be a 'de-shadowing' pass. The resulting AST would only see variables assigned only once.
Then a type-inference pass, where your AST expressions would gain type info.
(Then a bunch more passes, e.g. closure conversion if you have them)
Then towards the end you could lower your typed AST into a typed instruction list (having the SSA property - but nothing to do with allowing variables and their types to shadow earlier in the pipeline)
Shadowing at AST level with the lexical scope is easy to implement, it's just each usage looks up inside out to parent scopes. But if we treat each assignment as a kind of shadowing, it works in a similar way and turns into a kind of SSA. The complexity arises with phi-nodes when multiple paths join. I think the confusion comes from the strict definition of SSA as something useful for the very late stage in the pipeline, but the same concept can exist much earlier in the pipeline.
At least in my understanding of SSA, its a compiler implementation detail which makes writing optimizations simpler. I imagine you can implement flow typing without SSA.
At least Options+ application works. I tried this one in June with my M720, which I like a lot, and it could not even detect it. Alpha quality at best. As another comment mentioned, the air-gapped download for Options+ is fine. Yes, Options+ is total garbage, and I noticed its autoupdate did not remove previous versions, so I noticed it as a huge multi GB folder. But it works, while OpenLogi does not.
This is something I'm ready to pay for. Not more per token, but I will be happy to burn through 20x Pro subscription as fast as I consume my Plus weekly limit now, with 10x more tokens per unit of time. I've learned how to deal with and steer Sol medium quite efficiently, but at the same time I realize it's so slow for the small tasks it can do well, and still so unreliable for open-ended tasks.
I've seen dozens of videos and articles about this strongest ever event. And I still have no clue if the next year I should evacuate from Paris for the summer because heatwaves may be even crazier than this year, or prolonged heavy rains are more likely and can make the city more livable.
Given what I learned from "chaos" by James Gleick, the predicament we're in is that we likely cannot predict outcomes or the events themselves, rather what we know is that weather will become more unpredictable and more extreme.
So the answer to your question is it could be either or both or neither. Whatever happens is going to be on average more extreme than what you're used to.
It might end up like a covid situation where even if you have good AC in your home, you don't want to be in the area because the medical system is on its knees overwhelmed from treating all the cases of heat related illnesses.
It's funny that I said "evacuate" and did not mention air travel. In that part of the world, trains are the default, with nuclear green power powering the majority of consumers. Maybe that other default is a problem. And yes, bien sûr, an abandoned personal flight or train will counter balance China, India or mega leaks of methane in US. And all AC owners must be incarcerated, it's so worse than a car. A new leftist mayor of Paris even said ACs warm up neighbors' places, should be forbidden obviously...
As someone who had to do exactly that this summer (multiple times, to boot), I'm doing my part and working to get the fuck out of here permanently before next summer hits.
I've got an excellent overview of consequences from Claude Opus 5. I'd post it here but there's a "no AI content" policy, so sorry, you need to ask yourself. (Though for Europe specifically, apparently very little except for higher average temperatures).
What's worse than an AI generated comment... a comment about having generated an AI comment that you can't read!
If it's useful to the conversation (and objective + with sources) post the key findings - IMO I think it's AI generated prose / subjective posts that will get blasted.
I had plans to buy two Airs, was not sure if I needed 13 or 15, 24 or 32, which was better for my wife and what's the best strategy to buy one for her first and then understand my needs test-driving it. Maybe I actually needed Pro. Lot's of procrastination as none of us had a real need for an upgrade. It's all in the past tense now. I've just bought a 16GB model with 1TB on Amazon at 480 EUR cheaper that the new price, and it seems cheaper than the official old price. I will forget about MacBooks until a real need comes, or maybe good ARM laptops happen sooner. It's funny that if they did not have the dichotomy between 13 and 15, I would have thought less and bought M4 as soon as it was out with the support for 2 external displays + built-in.
In the context of a proxy one should mention epoll_wait busy poll. I've recently dived into this when reviewing low-latency options, and found that it's almost possible to do user space busy polling just for simple sockets, no DPDK/VMA/io_uring needed, and Fastly contributed to this and uses it.
It's too low level, I cannot even tell that I understand everything, only the concept, so I will just share some links. It works only per NAPI epoll context, and one cannot easily control NAPI ID, but if an entire machine is dedicated for a proxy one can do a simple trick of assinging sockets by NAPI ID to dedicated pollers.
In my use case, it was not a proxy, but N socket polling on a machine that then processes received data. It does not look feasible for such case, maybe round-robin polling of NAPI contexts from a single thread may work. What I would really want to have one day from the kernel is that I can easily tell it: trust me, I will poll this single socket eventually, never ever use IRQ path for it.
Picollo is a new library for serious performance work in .NET. Picollo stands for Performance Instrumentation and Continuous Observation for Low-Level Optimization. The initial public release of Picollo v0.1.0 contains two components. First, a modern version of an HDR histogram, which is much faster for recording data and easier to use. Second, a set of APIs for `perf_event_open`, including fast-path reads, that give raw access to PMU counters from .NET on Linux, WSL included.
And setting that env var should require a notarized consent to track contract that has an expiration of at most 60 days and has penalties of jail time for any data related to that telemetry, anonymized or not that is shared with a third party, for any reason, including but not limited to fulfilling the service the business purports to be providing.
It should be much more difficult to collect data than to opt out of collection.
TrueNAS works perfectly as a VM eg on Proxmox with passing through a SATA controller from the motherboard. It may not work always with bad IOMMU groups, but I have this on an old Xeon Precision Tower 3420 and not so old Asus Z690 motherboard. NVMe passthrough should be straightforward as well. No need for LSIs or cheap PCI-to-SATA cards if the number of existing physical slots is enough. And as far as TrueNAS is concerned, it's baremetal disk access. Even the latest TrueNAS is not in the same league as Proxmox for managing VMs/containers, not even close.
For some time recently, I was zooming in on Bosch's The Garden of Earthly Delights. The floor's level of interactivity would be so nice there. At least on this floor, I can guess what's going on quite reliably. The experience is quite similar at some level though. I saw Bosch's originals (or 1-to-1 by size repros) many years ago and without zooming in, it was incomprehensible. With zoom, the details are overwhelming.
Note this digitisation was by a company called Mad Pixel, and supported by Google in 2009. It was the first experiment that later became the Google Art Project in 2011 (now Google Arts & Culture).
reply